From Florin.Balus@alcatel-lucent.com Fri May 1 12:38:16 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD4D28C203 for ; Fri, 1 May 2009 12:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCQArCZclLmY for ; Fri, 1 May 2009 12:38:15 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 4130B3A6E68 for ; Fri, 1 May 2009 12:36:41 -0700 (PDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n41Jc3ei006245; Fri, 1 May 2009 14:38:05 -0500 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 14:38:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 14:37:57 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B055ED0B3@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <1477DEAE19DD884CB004730D0FD77FD701E9B7BB@misout7msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcnCwAoGFQKo2rg4SumWrxeo7E2d7QAfDjowAdX+CHA= References: <1477DEAE19DD884CB004730D0FD77FD701E9B7BB@misout7msgusr7e.ugd.att.com> From: "BALUS Florin" To: , X-OriginalArrivalTime: 01 May 2009 19:38:04.0102 (UTC) FILETIME=[583B4660:01C9CA94] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:38:16 -0000 Yes. > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Yakov Rekhter > Sent: Tuesday, April 21, 2009 4:16 PM > To: idr@ietf.org > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > Folks, >=20 > While we had a fair amount of e-mail exchange related to > draft-rosen-idr-aigp-00.txt, it is not clear whether we have a > consensus on adopting it as an IDR WG document. >=20 > To reach a closure on this, I would like to ask you to send either > "yes" or "no" e-mail ("yes" means accept, "no" means do not accept). > The deadline is May 6, 2009. >=20 > Also, keep in mind that silence counts as a lack of interest, and > a lack of interest means that that the document should not be adopted > as an IDR WG document. >=20 > Yakov. > ------- Forwarded Message >=20 > Date: Wed, 25 Mar 2009 06:51:28 -0700 > From: Yakov Rekhter > To: idr@ietf.org > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > Folks, >=20 > We received a request to accept draft-rosen-idr-aigp-00.txt as an > IDR WG document. The deadline for comments on this request is April > 8, 2009. >=20 > If anyone is aware of the IPR related to the draft, please follow > the procedurs of rfc3979. >=20 > Yakov. > - ------- Forwarded Message >=20 > Date: Tue, 24 Mar 2009 22:09:29 -0700 > From: "Pradosh Mohapatra (pmohapat)" > To: "idr" > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > The authors would like to request that draft-rosen-idr-aigp-00.txt > be adopted as an IDR WG document. We presented it yesterday @ IDR. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > - ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From mnapierala@att.com Tue May 5 07:25:37 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E5A3A71D6 for ; Tue, 5 May 2009 07:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.303 X-Spam-Level: X-Spam-Status: No, score=-106.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L43qKECAxDg for ; Tue, 5 May 2009 07:25:36 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 4976C3A71C8 for ; Tue, 5 May 2009 07:25:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mnapierala@att.com X-Msg-Ref: server-5.tower-167.messagelabs.com!1241533615!12799534!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 11235 invoked from network); 5 May 2009 14:26:56 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-5.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 May 2009 14:26:56 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n45EQtHc029947 for ; Tue, 5 May 2009 10:26:55 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n45EQoxc029864 for ; Tue, 5 May 2009 10:26:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 10:26:49 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A20027B7DC1@misout7msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcnNjYbX5eOM3K2MTXinkAsIclY/8Q== From: "NAPIERALA, MARIA H, ATTLABS" To: Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:25:37 -0000 I support adoption of this document. From zali@cisco.com Tue May 5 07:29:24 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB903A6BBB for ; Tue, 5 May 2009 07:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqGmhaWpZ8Ak for ; Tue, 5 May 2009 07:29:23 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5F72C3A686C for ; Tue, 5 May 2009 07:29:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,297,1238976000"; d="scan'208";a="43373466" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 May 2009 14:30:49 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n45EUnI9010780; Tue, 5 May 2009 10:30:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n45EUnAA001489; Tue, 5 May 2009 14:30:49 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 10:30:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 10:29:56 -0400 Message-ID: In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A20027B7DC1@misout7msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document thread-index: AcnNjYbX5eOM3K2MTXinkAsIclY/8QAAGe+w References: <2F1DE4DFCFF32144B771BD2C246E6A20027B7DC1@misout7msgusr7e.ugd.att.com> From: "Zafar Ali (zali)" To: "NAPIERALA, MARIA H, ATTLABS" , X-OriginalArrivalTime: 05 May 2009 14:30:49.0296 (UTC) FILETIME=[15E21D00:01C9CD8E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14; t=1241533849; x=1242397849; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20RE=3A=20[Idr]=20=20draft-rosen-idr-aigp-00.txt= 20as=20IDR=20WG=20document |Sender:=20 |To:=20=22NAPIERALA,=20MARIA=20H,=20ATTLABS=22=20,=20; bh=j3g6+car1XOmCAA3bfdeX8EEWtWz1+vXGwm6n6Y01G8=; b=xpx/dExP3iJ52OCcJaYrwXMXIJ0BYRBkOnlXQSVfgJFIYWl/hhBYXMsV54 9/PejoNzJHoJqcNQ3trHPz5spZj0v3I1RyfX8ggvnh1M1HxnGg+cNWfhPqsy m5gOJfOdTw; Authentication-Results: rtp-dkim-2; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:29:24 -0000 In Favor.=20 From johngibbons@att.com Tue May 5 08:05:10 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0624D3A6781 for ; Tue, 5 May 2009 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.378 X-Spam-Level: X-Spam-Status: No, score=-106.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjUT6xQdbUDE for ; Tue, 5 May 2009 08:05:08 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id BCEDB3A6859 for ; Tue, 5 May 2009 08:05:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: johngibbons@att.com X-Msg-Ref: server-6.tower-161.messagelabs.com!1241535992!14286756!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 3371 invoked from network); 5 May 2009 15:06:33 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 May 2009 15:06:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n45F6W5c031088 for ; Tue, 5 May 2009 11:06:32 -0400 Received: from misout7msgusr7d.ugd.att.com (misout7msgusr7d.ugd.att.com [144.155.43.106]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n45F6R7L031017 for ; Tue, 5 May 2009 11:06:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CD93.10255F63" Date: Tue, 5 May 2009 11:07:11 -0400 Message-ID: <81E7EA224F3BBA42B63EA69EFE971C01029FFE1D@misout7msgusr7d.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcnM/8lpJBTpTqfxR7Ocufc4GPFnBwAkmySA From: "GIBBONS, JOHN, ATTLABS" To: Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 15:05:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CD93.10255F63 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > I support this draft. >=20 > John Gibbons > AT&T Labs > 518-877-9213 >=20 ------_=_NextPart_001_01C9CD93.10255F63 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-rosen-idr-aigp-00.txt as IDR WG document

[Idr] draft-rosen-idr-aigp-00.txt as = IDR WG document

I support this draft.

John Gibbons
AT&T Labs
518-877-9213

------_=_NextPart_001_01C9CD93.10255F63-- From Faisal.Hashmi@alcatel-lucent.com Tue May 5 12:03:41 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6373A6DF7 for ; Tue, 5 May 2009 12:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwiXTLfrNW4y for ; Tue, 5 May 2009 12:03:41 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 1D77F3A698C for ; Tue, 5 May 2009 12:03:28 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n45J4sB9015625 for ; Tue, 5 May 2009 14:04:54 -0500 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.10]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 14:04:53 -0500 Received: from USDALSMBS04.ad3.ad.alcatel.com ([172.22.216.9]) by USDALSMBS01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 14:04:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 14:04:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rosen-idr-aigp-00.txt Thread-Index: AcnNtF6J7sC88xNZQuCrQAcHSHVqZQ== From: "HASHMI Faisal" To: X-OriginalArrivalTime: 05 May 2009 19:04:53.0504 (UTC) FILETIME=[5F652000:01C9CDB4] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Subject: [Idr] draft-rosen-idr-aigp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:06:54 -0000 [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document=20 I support this draft.=20 Thanks, Faisal Hashmi Senior Systems Engineer Alcatel-Lucent 732 614 4081 CCIE Service Provider. CCIE#19248 Project Management Professional (PMP) From jzatloukal@att.com Wed May 6 19:40:38 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7913A68D5 for ; Wed, 6 May 2009 19:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfYGnyFAS96i for ; Wed, 6 May 2009 19:40:35 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id EB9AA3A6874 for ; Wed, 6 May 2009 19:40:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jzatloukal@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1241664121!34198931!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 3650 invoked from network); 7 May 2009 02:42:01 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2009 02:42:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n472fopq004043 for ; Wed, 6 May 2009 22:41:51 -0400 Received: from misout7msgusr7d.ugd.att.com (misout7msgusr7d.ugd.att.com [144.155.43.106]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n472fkUI004020 for ; Wed, 6 May 2009 22:41:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CEBD.5D242511" Date: Wed, 6 May 2009 22:41:45 -0400 Message-ID: <81E7EA224F3BBA42B63EA69EFE971C0102A33440@misout7msgusr7d.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document - Support Thread-Index: AcnOi6KD+kG12ZImTUCQ2JTZM8xM7wAMaRTQ From: "ZATLOUKAL, JAMES W (JIM), ATTOPS" To: Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document - Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 02:40:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CEBD.5D242511 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to register my support for the Accumulated IGP Metric Attribute for BGP as defined in the draft-rosen-idr-aigp-00.txt document. This capability is critical to AT&T's plans for scaling its global IP/MPLS network.=20 =20 Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document =20 James (Jim) W. Zatloukal=20 AT&T Operations - Executive Director, Advanced Technical Support=20 Phone: +1.630-393-5440; Cell: +1.847-922-3338=20 eMail: jzatloukal@att.com=20 28 W 615 Ferry Road, Office A7=20 Warrenville, IL 60555=20 This email and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited. ------_=_NextPart_001_01C9CEBD.5D242511 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document - = Support

I’d like to = register my support for the Accumulated IGP Metric Attribute for BGP as defined in the draft-rosen-idr-aigp-00.txt = document. This capability is critical to AT&T’s = plans for scaling its global IP/MPLS network.

 

Re: = [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document

 

James (Jim) W. Zatloukal
AT&T Operations - = Executive Director, Advanced = Technical Support
Phone: +1.630-393-5440; = Cell: +1.847-922-3338
eMail: = jzatloukal@att.com
28 W 615 Ferry Road, Office = A7
Warrenville, IL = 60555

This email and any files transmitted with it are = AT&T property, are confidential, and are intended solely for the use of the individual or entity = to whom this email is addressed.  If you are not one of the named = recipient(s) or otherwise have reason to believe that you have received = this message in error, please notify the sender and delete = this message immediately from your computer.  Any other = use, retention, dissemination, forwarding, printing or copying of this = email is strictly prohibited.

------_=_NextPart_001_01C9CEBD.5D242511-- From wim.henderickx@alcatel-lucent.be Wed May 6 22:07:04 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929A93A683B for ; Wed, 6 May 2009 22:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1He1GIMTCsPs for ; Wed, 6 May 2009 22:07:03 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 6B7723A69C3 for ; Wed, 6 May 2009 22:07:03 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4758SJT019554 for ; Thu, 7 May 2009 07:08:28 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 07:08:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CED1.DB72914B" Date: Thu, 7 May 2009 07:08:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document - Support Thread-Index: AcnO0dskHAieNo5+SHKzcpAIzJGf/g== From: "HENDERICKX Wim" To: X-OriginalArrivalTime: 07 May 2009 05:08:28.0247 (UTC) FILETIME=[DB7A1E70:01C9CED1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document - Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 05:07:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CED1.DB72914B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable support ------_=_NextPart_001_01C9CED1.DB72914B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document - = Support

support

------_=_NextPart_001_01C9CED1.DB72914B-- From yakov@juniper.net Thu May 7 06:38:41 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B034F28C0F9 for ; Thu, 7 May 2009 06:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sA6u+52EFNk for ; Thu, 7 May 2009 06:38:40 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id D2A4A3A6FB2 for ; Thu, 7 May 2009 06:38:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSgLkt3MbAvoaFmsZnS+N7T2ek6KRGdBo@postini.com; Thu, 07 May 2009 06:40:09 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 7 May 2009 06:34:09 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 06:34:09 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 06:34:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 06:34:07 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n47DY7L40546 for ; Thu, 7 May 2009 06:34:07 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200905071334.n47DY7L40546@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75675.1241703247.1@juniper.net> Date: Thu, 7 May 2009 06:34:07 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 07 May 2009 13:34:07.0919 (UTC) FILETIME=[7F54ABF0:01C9CF18] Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 13:38:41 -0000 Folks, draft-rosen-idr-aigp-00.txt is accepted as an IDR WG document. Authors of the document should resubmit it as draft-ietf-idr-aigp-00.txt. Yakov. From htong@att.com Mon May 4 13:59:33 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D053A70CA for ; Mon, 4 May 2009 13:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMiHsHJYS6Ua for ; Mon, 4 May 2009 13:59:33 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 07D343A70AF for ; Mon, 4 May 2009 13:59:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: htong@att.com X-Msg-Ref: server-5.tower-129.messagelabs.com!1241470857!13937808!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 19450 invoked from network); 4 May 2009 21:00:58 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-5.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2009 21:00:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n44L0vjH007329 for ; Mon, 4 May 2009 17:00:57 -0400 Received: from gaalpa1msgusr7c.ugd.att.com (gaalpa1msgusr7c.ugd.att.com [135.53.26.17]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n44L0phY007275 for ; Mon, 4 May 2009 17:00:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CCFB.683BA751" Date: Mon, 4 May 2009 17:00:50 -0400 Message-ID: <476B7D1A60E42D4F9A0E43FB76C93E49026603FA@gaalpa1msgusr7c.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcnM+2fNkwebvWTZS5ujoZY8INlNVA== From: "TONG, HUI, ATTLABS" To: X-Mailman-Approved-At: Fri, 08 May 2009 08:14:32 -0700 Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:01:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CCFB.683BA751 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I support this document. Hui Tong "This email and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this email is strictly prohibited." ------_=_NextPart_001_01C9CCFB.683BA751 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document

I support this document.

Hui Tong

"This email and any files = transmitted with it are AT&T property, are confidential, and are = intended solely for the use of the individual or entity to whom this = email is addressed. If you are not one of the named recipient(s) or = otherwise have reason to believe that you have received this message in = error, please notify the sender and delete this message immediately from = your computer. Any other use, retention, dissemination, forwarding, = printing, or copying of this email is strictly = prohibited."


------_=_NextPart_001_01C9CCFB.683BA751-- From rpulipati@att.com Tue May 5 02:42:59 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC5F3A6855 for ; Tue, 5 May 2009 02:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl0GQU249ZXA for ; Tue, 5 May 2009 02:42:59 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 1347F3A6949 for ; Tue, 5 May 2009 02:42:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: rpulipati@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1241516663!22356044!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 29690 invoked from network); 5 May 2009 09:44:24 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-4.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 May 2009 09:44:24 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n459iNiP026805 for ; Tue, 5 May 2009 05:44:23 -0400 Received: from misout7msgusr7c.ugd.att.com (misout7msgusr7c.ugd.att.com [144.155.43.105]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n459iKcx026794 for ; Tue, 5 May 2009 05:44:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CD66.10A86773" Date: Tue, 5 May 2009 05:44:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Idr] draft-rosen-idr-aigp-00.txt Thread-Index: AcnNZf5oPpbzYJqWSterl+3xkHEedQ== From: "PULIPATI, RAVI, ATTLABS" To: X-Mailman-Approved-At: Fri, 08 May 2009 08:14:32 -0700 Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 09:58:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CD66.10A86773 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I strongly support this document. I believe it really helps many ISP's in Inter-AS solutions to keep it simple. Regards, Ravi ------_=_NextPart_001_01C9CD66.10A86773 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Idr] draft-rosen-idr-aigp-00.txt

Hi,

I strongly support this = document. I believe it really helps many ISP's in Inter-AS solutions to = keep it simple.

Regards,
Ravi

------_=_NextPart_001_01C9CD66.10A86773-- From web-usrn@ISI.EDU Tue May 5 09:02:00 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BCCF3A6C0E for ; Tue, 5 May 2009 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.222 X-Spam-Level: X-Spam-Status: No, score=-17.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO0fX6DUPW9y for ; Tue, 5 May 2009 09:01:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id D99373A6CD9 for ; Tue, 5 May 2009 09:01:06 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n45Fwo0x021386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 May 2009 08:58:50 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n45FwkA3021365; Tue, 5 May 2009 08:58:46 -0700 (PDT) Date: Tue, 5 May 2009 08:58:46 -0700 (PDT) Message-Id: <200905051558.n45FwkA3021365@boreas.isi.edu> To: tbates@cisco.com, rchandra@sonoasystems.com, dkatz@juniper.com, yakov@juniper.com, rcallon@juniper.net, adrian.farrel@huawei.com, shares@ghs.com, yakov@juniper.net From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Fri, 08 May 2009 08:14:32 -0700 Cc: nmalykh@protocols.ru, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4760 (1778) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:02:00 -0000 The following errata report has been submitted for RFC4760, "Multiprotocol Extensions for BGP-4". -------------------------------------- You may review the report below and at: http://rfc-editor.org/errata_search.php?rfc=4760&eid=1778 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3 Original Text ------------- An UPDATE message SHOULD NOT include the same address prefix (of the same ) in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The processing of an UPDATE message in this form is undefined. Corrected Text -------------- An UPDATE message SHOULD NOT include the same address prefix (of the same ) in more than one of the following fields: WITHDRAWN ROUTES field, Network Layer Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The processing of an UPDATE message in this form is undefined. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4760 (draft-ietf-idr-rfc2858bis-10) -------------------------------------- Title : Multiprotocol Extensions for BGP-4 Publication Date : January 2007 Author(s) : T. Bates, R. Chandra, D. Katz, Y. Rekhter Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From rkarim@att.com Tue May 5 14:26:36 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F21C3A6BA0 for ; Tue, 5 May 2009 14:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTMcBYB6rA5S for ; Tue, 5 May 2009 14:26:35 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 8E97928C121 for ; Tue, 5 May 2009 14:26:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: rkarim@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1241558872!23926769!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 18800 invoked from network); 5 May 2009 21:27:52 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-12.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 May 2009 21:27:52 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n45LRqfe010950 for ; Tue, 5 May 2009 17:27:52 -0400 Received: from gaalpa1msgusr7c.ugd.att.com (gaalpa1msgusr7c.ugd.att.com [135.53.26.17]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n45LRj0A010883 for ; Tue, 5 May 2009 17:27:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CDC8.543FB901" Date: Tue, 5 May 2009 17:27:44 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcnMrZtl7wlKfV00Ru+4Cxx/hqUaQAADm4fgAEMNwyA= References: <1477DEAE19DD884CB004730D0FD77FD701E9B7FD@misout7msgusr7e.ugd.att.com> From: "KARIM, REHAN, ATTLABS" To: X-Mailman-Approved-At: Fri, 08 May 2009 08:14:32 -0700 Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:28:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CDC8.543FB901 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I support this draft.=20 =20 Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document =20 __________________________ Rehan Karim Technology Introduction, Tier4=20 at&t Labs W: 732 420 0084 email: rkarim@att.com =20 ------_=_NextPart_001_01C9CDC8.543FB901 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I=20 support this draft.
 
Re: [Idr]=20 draft-rosen-idr-aigp-00.txt as IDR WG document
 
__________________________
Rehan=20 Karim
Technology Introduction, Tier4
at&t=20 Labs
W: = 732 420=20 0084
email:=20 rkarim@att.com

 
------_=_NextPart_001_01C9CDC8.543FB901-- From samirs@att.com Wed May 6 06:37:54 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B67C3A6DE5 for ; Wed, 6 May 2009 06:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5bfHUts6kk6 for ; Wed, 6 May 2009 06:37:53 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id E43013A6CFE for ; Wed, 6 May 2009 06:35:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: samirs@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1241617026!29202002!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 1600 invoked from network); 6 May 2009 13:37:07 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 May 2009 13:37:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n46Db6um009279 for ; Wed, 6 May 2009 09:37:06 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n46DaxLQ009157 for ; Wed, 6 May 2009 09:37:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CE4F.BB5A88FD" Date: Wed, 6 May 2009 09:36:57 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcnOT7n1mu28Qdn5SZaM2kDc9JKkJg== From: "SAAD, SAMIR S, ATTLABS" To: X-Mailman-Approved-At: Fri, 08 May 2009 08:14:32 -0700 Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:37:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CE4F.BB5A88FD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I am in support of the draft-rosen-idr-aigp-00.txt as an IDR WG draft as it is of great interest and value to the work I am doing. Samir Saad Lead Member of Technical Staff AT&T IP Global Network Design ------_=_NextPart_001_01C9CE4F.BB5A88FD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document

I am in support of the draft-rosen-idr-aigp-00.txt = as an IDR WG draft as it is = of great interest and value to the work I am doing.

Samir Saad

Lead Member of Technical Staff

AT&T IP Global Network Design

------_=_NextPart_001_01C9CE4F.BB5A88FD-- From root@core3.amsl.com Fri May 8 14:45:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9FE1D3A7144; Fri, 8 May 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090508214501.9FE1D3A7144@core3.amsl.com> Date: Fri, 8 May 2009 14:45:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-aigp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 21:45:01 -0000 --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 : The Accumulated IGP Metric Attribute for BGP Author(s) : R. Fernando, et al. Filename : draft-ietf-idr-aigp-00.txt Pages : 13 Date : 2009-05-08 Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aigp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-aigp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-08144246.I-D@ietf.org> --NextPart-- From yakov@juniper.net Tue May 12 12:36:10 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011FF3A6EC4 for ; Tue, 12 May 2009 12:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge0iqloZHtRS for ; Tue, 12 May 2009 12:36:09 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 0DA2C3A6E46 for ; Tue, 12 May 2009 12:36:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSgnP/VIqaoVO+VgVIQQvHPDZJbhoABE/@postini.com; Tue, 12 May 2009 12:37:34 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 12 May 2009 12:33:33 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 May 2009 12:33:33 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 May 2009 12:33:33 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 May 2009 12:33:32 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n4CJXWL82290 for ; Tue, 12 May 2009 12:33:32 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200905121933.n4CJXWL82290@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90375.1242156812.1@juniper.net> Date: Tue, 12 May 2009 12:33:32 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 12 May 2009 19:33:32.0378 (UTC) FILETIME=[88D0BBA0:01C9D338] Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 19:36:10 -0000 Folks, draft-marques-idr-best-external-01.txt is accepted as an IDR WG doc. Authors of the document should resubmit it as draft-ietf-idr-best-external-00.txt. Yakov. From root@core3.amsl.com Fri May 15 07:45:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6DCC23A70E8; Fri, 15 May 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515144501.6DCC23A70E8@core3.amsl.com> Date: Fri, 15 May 2009 07:45:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-best-external-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:45:01 -0000 --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 : Advertisement of the best external route in BGP Author(s) : P. Roque Marques, et al. Filename : draft-ietf-idr-best-external-00.txt Pages : 11 Date : 2009-05-14 The base BGP specifications prevent a BGP speaker from advertising any route that is not the best route for a BGP destination. This document specifies a modification of this rule. Routes are divided into two categories, "external" and "internal". A specification is provided for choosing a "best external route" (for a particular value of the Network Layer Reachability Information). A BGP speaker is then allowed to advertise its "best external route" to its internal BGP peers, even if that is not the best route for the destination. The document explains why advertising the best external route can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. The document also generalizes the notions of "internal" and "external" so that they can be applied to Route Reflector Clusters and Autonomous System Confederations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-best-external-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-best-external-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15073205.I-D@ietf.org> --NextPart-- From Roberto.Fragassi@alcatel-lucent.com Wed May 20 06:31:36 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148933A6D02 for ; Wed, 20 May 2009 06:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK3CNCuvS3nH for ; Wed, 20 May 2009 06:31:30 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id E7A1228C30D for ; Wed, 20 May 2009 06:31:25 -0700 (PDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id n4KDX2SX015372 for ; Wed, 20 May 2009 08:33:02 -0500 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.9]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 08:33:02 -0500 Received: from USDALSMBS05.ad3.ad.alcatel.com ([172.22.216.34]) by USDALSMBS01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 08:33:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D94F.7FBE7B63" Date: Wed, 20 May 2009 08:33:01 -0500 Message-ID: <09A656CD8EE63F42982A7964FEEDB17D02168669@USDALSMBS05.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt Thread-Index: AcnZT38T/yxOVK9/RuKZBMpIsDDocg== From: "FRAGASSI Roberto" To: X-OriginalArrivalTime: 20 May 2009 13:33:02.0924 (UTC) FILETIME=[7FF5F8C0:01C9D94F] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Subject: [Idr] draft-rosen-idr-aigp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 13:31:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D94F.7FBE7B63 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document I support this draft. thanks, =20 Roberto Fragassi Consulting Engineer - IPCC Business Development Alcatel-Lucent Cell 908 304 5537 =20 =20 ------_=_NextPart_001_01C9D94F.7FBE7B63 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
[Idr] draft-rosen-idr-aigp-00.txt as IDR WG = document

I=20 support this draft.
thanks,
 
Roberto = Fragassi
Consulting Engineer - = IPCC
Business = Development
Alcatel-Lucent
Cell 908 304 = 5537
 
 
------_=_NextPart_001_01C9D94F.7FBE7B63-- From robert@raszuk.net Wed May 20 09:16:40 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760C53A6C0C for ; Wed, 20 May 2009 09:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDPIUUVuLIsF for ; Wed, 20 May 2009 09:16:39 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 114DE3A684E for ; Wed, 20 May 2009 09:16:15 -0700 (PDT) Received: (qmail 17075 invoked by uid 399); 20 May 2009 16:17:52 -0000 Received: from unknown (HELO ?192.168.1.160?) (83.24.14.220) by mail37.opentransfer.com with SMTP; 20 May 2009 16:17:52 -0000 Message-ID: <4A142D28.4000806@raszuk.net> Date: Wed, 20 May 2009 09:17:44 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: idr Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 16:16:40 -0000 Hi, I am proposing the below enhancement to add-paths document: Thx, R. 5. ADD-PATH Capability The ADD-PATH Capability is a new BGP capability [RFC3392]. The Capability Code for this capability is specified in the IANA Considerations section of this document. The Capability Length field of this capability is variable. The Capability Value field consists of one or more of the following tuples: +------------------------------------------------+ | Address Family Identifier (2 octets) | +------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +------------------------------------------------+ | Send/Receive (1 octet) | +------------------------------------------------+ | Requested Number of Paths (1 octet) | +------------------------------------------------+ The meaning and use of the fields are as follows: Address Family Identifier (AFI): This field is the same as the one used in [RFC4760]. Subsequent Address Family Identifier (SAFI): This field is the same as the one used in [RFC4760]. Send/Receive: This field indicates whether the sender is (a) willing to receive multiple paths from its peer (value 1), (b) would like to send multiple paths to its peer (value 2), or (c) both (value 3) for the . Requested number of Paths: This field indicates maximum number of paths bgp speaker is willing to receive from it's peer for given AFI/SAFI. If Send/Receive field has the value of 2 the value of this field should be 0. *** Justification to go to 6. Operation section: The ability to signal how many paths bgp speaker has requested to be received has a significant operational advantage. As different routers have different roles in the network they need different number of paths to realize their application. As example ASBR willing to provide backup as well as load balancing may need more bgp paths then a P router just interested in backup application. Configuring all of those specific per peer information on for example a route reflector for hundreds of peers may result in configuration overhead and provisioning errors which can be easily avoided by the above extension. From the bgp speaker perspective such number can be considered just as a hint. An implementation may decide to overwrite it and to not comply with it. From cayle.spandon@gmail.com Wed May 20 11:52:33 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0493A6AC4 for ; Wed, 20 May 2009 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmDUX+O8oSWk for ; Wed, 20 May 2009 11:52:32 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 443513A6CE3 for ; Wed, 20 May 2009 11:52:32 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so657276yxb.49 for ; Wed, 20 May 2009 11:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1siBOdCE4fI45WA98Jppe4tPbLdpVAuexzo9YodfulI=; b=BC8dXVbI/o2HsPFr8B5qGUGuJWQ62VGNf+rwyU5cSSScM8s5/kRGbqT5ahKlykY+vh HgkIRuuyiLg9c8eqN/s4kh+cLfFRjk9iLiSVJ2tPeVXcR7a55AcBcnJWBmoE/VAm2XL9 CZDf3Ho1WWp97Zy3Xv9TN9Wb9LNHScCAnhM/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RdhKcJHpvNy/whnbSxymdJhtNETA3GfjVg2OconXAVLkZcXAb7YMycdPEZdF5URzJ1 hG3dyuplvSt0l/emnPoGAgCyML2owpGSdvzt3L2WzOZ919Tp+uNBeLzI5rdsBQJUzego 8y42BSxKTjEcP0p8p98qDtyiDg/j2W8OwQx68= MIME-Version: 1.0 Received: by 10.150.189.1 with SMTP id m1mr2792460ybf.335.1242845646787; Wed, 20 May 2009 11:54:06 -0700 (PDT) In-Reply-To: <4A142D28.4000806@raszuk.net> References: <4A142D28.4000806@raszuk.net> Date: Wed, 20 May 2009 14:54:06 -0400 Message-ID: <71c13900905201154x404e81cev8f375f0872c49acd@mail.gmail.com> From: Cayle Spandon To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 18:52:33 -0000 I agree that adding the enhancement is useful. > =A0From the bgp speaker perspective such number can be considered > =A0just as a hint. An implementation may decide to overwrite it > =A0and to not comply with it. However, the above paragraph seems a little bit too permissive to me. How about something a bit more strict: "A sender may choose to send fewer paths than the receiver is willing to accept and fewer paths than are available to the destination. A sender must never send more paths than the receiver is willing to accept. For example, if there are 5 paths to a destination and the peer has indicated that it is willing to receive 4 paths, the sender may choose to send only 2 paths but it is not allowed to send all 5 paths." -- Cayle From robert@raszuk.net Wed May 20 12:03:23 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA21A3A7156 for ; Wed, 20 May 2009 12:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqFLyT-IRItn for ; Wed, 20 May 2009 12:03:23 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id CB2303A715D for ; Wed, 20 May 2009 12:02:01 -0700 (PDT) Received: (qmail 27189 invoked by uid 399); 20 May 2009 19:03:39 -0000 Received: from unknown (HELO ?192.168.1.160?) (83.24.14.220) by mail37.opentransfer.com with SMTP; 20 May 2009 19:03:39 -0000 Message-ID: <4A145402.5020909@raszuk.net> Date: Wed, 20 May 2009 12:03:30 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Cayle Spandon References: <4A142D28.4000806@raszuk.net> <71c13900905201154x404e81cev8f375f0872c49acd@mail.gmail.com> In-Reply-To: <71c13900905201154x404e81cev8f375f0872c49acd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 19:03:23 -0000 Hi Cayle, Many thx for the proposal of the alternative text. I would never said that better ! Cheers, R. > I agree that adding the enhancement is useful. > >> From the bgp speaker perspective such number can be considered >> just as a hint. An implementation may decide to overwrite it >> and to not comply with it. > > However, the above paragraph seems a little bit too permissive to me. > > How about something a bit more strict: > > "A sender may choose to send fewer paths than the receiver is willing > to accept and fewer paths than are available to the destination. A > sender must never send more paths than the receiver is willing to > accept. For example, if there are 5 paths to a destination and the > peer has indicated that it is willing to receive 4 paths, the sender > may choose to send only 2 paths but it is not allowed to send all 5 > paths." > > -- Cayle > > From enkechen@cisco.com Wed May 20 12:27:44 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973A83A6AB1 for ; Wed, 20 May 2009 12:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TecXC51ePBDv for ; Wed, 20 May 2009 12:27:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6A40C3A6A44 for ; Wed, 20 May 2009 12:27:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,223,1241395200"; d="scan'208";a="188217652" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 May 2009 19:29:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4KJTLt1015879; Wed, 20 May 2009 12:29:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4KJTLSk018492; Wed, 20 May 2009 19:29:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 12:29:20 -0700 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 12:29:20 -0700 Message-ID: <4A145A10.3060004@cisco.com> Date: Wed, 20 May 2009 12:29:20 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: robert@raszuk.net References: <4A142D28.4000806@raszuk.net> In-Reply-To: <4A142D28.4000806@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2009 19:29:20.0446 (UTC) FILETIME=[45F4F5E0:01C9D981] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3950; t=1242847761; x=1243711761; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20Requested=20number=20of=20paths =20enhancement=20for=20add-paths |Sender:=20; bh=O6lwE05/HDCcTPRzuIxSFyPYBPm7H3TqZOyEG0Tcumg=; b=HZfidZ90s0ni1GVQPofwPgC6bat4tvew/tCkTj5RXl9VP3nVe2iqb/ZZCD JA1teqg9ll5kmi/0BlJhtzOWzpIKhORZcQqk3e5EbEbR2RcKZ1ji0oNvrCZF t/HzoGj1JK; Authentication-Results: sj-dkim-3; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 19:27:44 -0000 Hi, Robert: The idea was proposed and debated before. The issue with the idea is that the receiver does not really know the number of paths that would be required for a particular application, and limiting the number of paths the sender can send may compromise a solution. For example, one solution for the route oscillation is to advertise all the group-best paths. The solution would be compromised if only a subset of the group-best paths were advertised. Given what you said in the email: ------------------------------------------ From the bgp speaker perspective such number can be considered just as a hint. An implementation may decide to overwrite it and to not comply with it. ------------------------------------------ I think that we are better off not to have it. Thanks. -- Enke Robert Raszuk wrote: > > > Hi, > > I am proposing the below enhancement to add-paths document: > > Thx, > R. > > > 5. ADD-PATH Capability > > The ADD-PATH Capability is a new BGP capability [RFC3392]. The > Capability Code for this capability is specified in the IANA > Considerations section of this document. The Capability Length field > of this capability is variable. The Capability Value field consists > of one or more of the following tuples: > > > +------------------------------------------------+ > | Address Family Identifier (2 octets) | > +------------------------------------------------+ > | Subsequent Address Family Identifier (1 octet) | > +------------------------------------------------+ > | Send/Receive (1 octet) | > +------------------------------------------------+ > | Requested Number of Paths (1 octet) | > +------------------------------------------------+ > > > The meaning and use of the fields are as follows: > > Address Family Identifier (AFI): > > This field is the same as the one used in [RFC4760]. > > Subsequent Address Family Identifier (SAFI): > > This field is the same as the one used in [RFC4760]. > > Send/Receive: > > This field indicates whether the sender is (a) willing to > receive multiple paths from its peer (value 1), (b) would > like to send multiple paths to its peer (value 2), or (c) > both (value 3) for the . > > Requested number of Paths: > > This field indicates maximum number of paths bgp speaker > is willing to receive from it's peer for given AFI/SAFI. > If Send/Receive field has the value of 2 the value of this > field should be 0. > > *** > > Justification to go to 6. Operation section: > > The ability to signal how many paths bgp speaker has > requested to be received has a significant operational > advantage. As different routers have different roles in > the network they need different number of paths to > realize their application. > > As example ASBR willing to provide backup as well as load > balancing may need more bgp paths then a P router just > interested in backup application. > > Configuring all of those specific per peer information on > for example a route reflector for hundreds of peers may > result in configuration overhead and provisioning errors > which can be easily avoided by the above extension. > > From the bgp speaker perspective such number can be considered > just as a hint. An implementation may decide to overwrite it > and to not comply with it. > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Wed May 20 12:41:16 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E6A28C0EC for ; Wed, 20 May 2009 12:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqBzeJvjjsdI for ; Wed, 20 May 2009 12:41:15 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 963F028C1AF for ; Wed, 20 May 2009 12:41:01 -0700 (PDT) Received: (qmail 26281 invoked by uid 399); 20 May 2009 19:42:38 -0000 Received: from unknown (HELO ?192.168.1.160?) (83.24.14.220) by mail37.opentransfer.com with SMTP; 20 May 2009 19:42:38 -0000 Message-ID: <4A145D26.5060407@raszuk.net> Date: Wed, 20 May 2009 12:42:30 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Enke Chen References: <4A142D28.4000806@raszuk.net> <4A145A10.3060004@cisco.com> In-Reply-To: <4A145A10.3060004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 19:41:16 -0000 Hi Enke, I think perhaps it requires second round of discussion. I can really see the benefit where you have a lot of paths for a given SAFI and P routers need only two while edge may need more. To distinguish by configuration 100s of IBGP clients of RR which would carry potentially 10s of paths if not more is a very much labor intensive and error prone configuration task. My intention is to eliminate such risk and easy the operator's life. In fact I would improve what I originally suggested which may address the case of application not capable of knowing in advance what number of paths to receive. (Personally I have heard from SPs that they would be quite conservative with distributing more then best path and if not per peer hard limit the number of paths on the sender side on a per SAFI basis. That would effectively have even worse effect for your example then my suggestion :). So the new text would say for section 5: Requested number of Paths: This field indicates maximum number of paths bgp speaker is willing to receive from it's peer for given AFI/SAFI. If Send/Receive field has the value of 2 the value of this field should be 0. When Send/Receive field has the value of 1 or 3 and Requested number of paths is set to 0 receiver is declaring willingness to accept all paths. With this in mind would you think we are better off ? Cheers, R. > Hi, Robert: > > The idea was proposed and debated before. The issue with the idea is > that the receiver does not really know the number of paths that would be > required for a particular application, and limiting the number of paths > the sender can send may compromise a solution. For example, one > solution for the route oscillation is to advertise all the group-best > paths. The solution would be compromised if only a subset of the > group-best paths were advertised. > > Given what you said in the email: > ------------------------------------------ > From the bgp speaker perspective such number can be considered > just as a hint. An implementation may decide to overwrite it > and to not comply with it. > ------------------------------------------ > > I think that we are better off not to have it. > > Thanks. -- Enke > > Robert Raszuk wrote: >> >> >> Hi, >> >> I am proposing the below enhancement to add-paths document: >> >> Thx, >> R. >> >> >> 5. ADD-PATH Capability >> >> The ADD-PATH Capability is a new BGP capability [RFC3392]. The >> Capability Code for this capability is specified in the IANA >> Considerations section of this document. The Capability Length field >> of this capability is variable. The Capability Value field consists >> of one or more of the following tuples: >> >> >> +------------------------------------------------+ >> | Address Family Identifier (2 octets) | >> +------------------------------------------------+ >> | Subsequent Address Family Identifier (1 octet) | >> +------------------------------------------------+ >> | Send/Receive (1 octet) | >> +------------------------------------------------+ >> | Requested Number of Paths (1 octet) | >> +------------------------------------------------+ >> >> >> The meaning and use of the fields are as follows: >> >> Address Family Identifier (AFI): >> >> This field is the same as the one used in [RFC4760]. >> >> Subsequent Address Family Identifier (SAFI): >> >> This field is the same as the one used in [RFC4760]. >> >> Send/Receive: >> >> This field indicates whether the sender is (a) willing to >> receive multiple paths from its peer (value 1), (b) would >> like to send multiple paths to its peer (value 2), or (c) >> both (value 3) for the . >> Requested number of Paths: >> This field indicates maximum number of paths bgp speaker >> is willing to receive from it's peer for given AFI/SAFI. >> If Send/Receive field has the value of 2 the value of this >> field should be 0. >> *** >> Justification to go to 6. Operation section: >> The ability to signal how many paths bgp speaker has >> requested to be received has a significant operational >> advantage. As different routers have different roles in >> the network they need different number of paths to >> realize their application. >> As example ASBR willing to provide backup as well as load >> balancing may need more bgp paths then a P router just >> interested in backup application. >> >> Configuring all of those specific per peer information on >> for example a route reflector for hundreds of peers may >> result in configuration overhead and provisioning errors >> which can be easily avoided by the above extension. >> >> From the bgp speaker perspective such number can be considered >> just as a hint. An implementation may decide to overwrite it >> and to not comply with it. >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > > From robert@raszuk.net Wed May 20 12:49:23 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA123A7170 for ; Wed, 20 May 2009 12:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1CPTbtsK-qJ for ; Wed, 20 May 2009 12:49:22 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 4FBF73A7173 for ; Wed, 20 May 2009 12:49:22 -0700 (PDT) Received: (qmail 867 invoked by uid 399); 20 May 2009 19:50:59 -0000 Received: from unknown (HELO ?192.168.1.160?) (83.24.14.220) by mail37.opentransfer.com with SMTP; 20 May 2009 19:50:59 -0000 Message-ID: <4A145F1B.2000508@raszuk.net> Date: Wed, 20 May 2009 12:50:51 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Enke Chen References: <4A142D28.4000806@raszuk.net> <4A145A10.3060004@cisco.com> In-Reply-To: <4A145A10.3060004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 19:49:23 -0000 Hi Enke, > The issue with the idea is that the receiver does not really know the number > of paths that would be required for a particular application I can easily think of a list of applications where the receiver does know how many paths he would need. If provider is willing to enable following applications he would configure corresponding value of the new Requested Number of Paths octet: * BGP fast connectivity restoration -> value of 2 * Better load balancing -> value of 2-4 * Oscillations -> value of 0 I think it would be great to hear from service providers if they want to have control over how many paths they may be getting from RR (including to allow all) or if they would open up all their edge routers to receive all RR would be willing to send ? Cheers, R. From manav@alcatel-lucent.com Wed May 20 16:07:30 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5465B3A68E8 for ; Wed, 20 May 2009 16:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq7hi3uWiMK8 for ; Wed, 20 May 2009 16:07:23 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id AD9C928C0E7 for ; Wed, 20 May 2009 16:07:22 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4KN8wSi004159 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 May 2009 01:08:58 +0200 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 21 May 2009 01:08:58 +0200 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 21 May 2009 04:38:56 +0530 From: "Bhatia, Manav (Manav)" To: "robert@raszuk.net" , idr Date: Thu, 21 May 2009 04:38:55 +0530 Thread-Topic: [Idr] Requested number of paths enhancement for add-paths Thread-Index: AcnZZqE0QtiOCXo3QN2Wcnxv1FE9EAAOLcOg Message-ID: <7C362EEF9C7896468B36C9B79200D835036080F9C2@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4A142D28.4000806@raszuk.net> In-Reply-To: <4A142D28.4000806@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 23:07:30 -0000 Hi Robert, On what basis would the sender decide the subset of routes it needs to adve= rtise? If you're doing ECMP then wouldn't you need to advertise *all* the i= nformation that you have? Cheers, Manav > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Robert Raszuk > Sent: Wednesday, May 20, 2009 9.48 PM > To: idr > Subject: [Idr] Requested number of paths enhancement for add-paths >=20 > >=20 > Hi, >=20 > I am proposing the below enhancement to add-paths document: >=20 > Thx, > R. >=20 >=20 > 5. ADD-PATH Capability >=20 > The ADD-PATH Capability is a new BGP capability [RFC3392]. The > Capability Code for this capability is specified in the IANA > Considerations section of this document. The Capability=20 > Length field > of this capability is variable. The Capability Value=20 > field consists > of one or more of the following tuples: >=20 >=20 > +------------------------------------------------+ > | Address Family Identifier (2 octets) | > +------------------------------------------------+ > | Subsequent Address Family Identifier (1 octet) | > +------------------------------------------------+ > | Send/Receive (1 octet) | > +------------------------------------------------+ > | Requested Number of Paths (1 octet) | > +------------------------------------------------+ >=20 >=20 > The meaning and use of the fields are as follows: >=20 > Address Family Identifier (AFI): >=20 > This field is the same as the one used in [RFC4760]. >=20 > Subsequent Address Family Identifier (SAFI): >=20 > This field is the same as the one used in [RFC4760]. >=20 > Send/Receive: >=20 > This field indicates whether the sender is (a) willing to > receive multiple paths from its peer (value 1), (b) would > like to send multiple paths to its peer (value 2), or (c) > both (value 3) for the . > =09 > Requested number of Paths: > =09 > This field indicates maximum number of paths bgp speaker > is willing to receive from it's peer for given AFI/SAFI. > If Send/Receive field has the value of 2 the value of this > field should be 0. > =09 > *** =09 >=20 > Justification to go to 6. Operation section: > =09 > The ability to signal how many paths bgp speaker has > requested to be received has a significant operational > advantage. As different routers have different roles in > the network they need different number of paths to > realize their application. > =09 > As example ASBR willing to provide backup as well as load > balancing may need more bgp paths then a P router just > interested in backup application. >=20 > Configuring all of those specific per peer information on > for example a route reflector for hundreds of peers may > result in configuration overhead and provisioning errors > which can be easily avoided by the above extension. >=20 > From the bgp speaker perspective such number can be considered > just as a hint. An implementation may decide to overwrite it > and to not comply with it. >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From robert@raszuk.net Wed May 20 16:20:20 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E833A6DDC for ; Wed, 20 May 2009 16:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm1wuzLI1Hrb for ; Wed, 20 May 2009 16:20:19 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 4DE253A6D49 for ; Wed, 20 May 2009 16:20:19 -0700 (PDT) Received: (qmail 2244 invoked by uid 399); 20 May 2009 23:21:56 -0000 Received: from unknown (HELO ?192.168.1.160?) (83.24.52.135) by mail37.opentransfer.com with SMTP; 20 May 2009 23:21:56 -0000 Message-ID: <4A14908B.90701@raszuk.net> Date: Wed, 20 May 2009 16:21:47 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4A142D28.4000806@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080F9C2@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D835036080F9C2@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 23:20:20 -0000 Hi Bhatia, > On what basis would the sender decide the subset of routes it needs > to advertise? On the basis of implementing ordered path list or on the basis of building group-best sets. Are you suggesting that add-paths draft should always send all paths it has for a given net ? If so let's make sure that such point of view is reflected in the specification. > If you're doing ECMP then wouldn't you need to > advertise *all* the information that you have? From the point of view of large networks I doubt seriously that even for ECMP (or unequal cost multi path for tunneled core) you need as many paths as number of your peering points to other transit ISPs. That number can be clearly in tens today. Cheers, R. > Hi Robert, > > On what basis would the sender decide the subset of routes it needs > to advertise? If you're doing ECMP then wouldn't you need to > advertise *all* the information that you have? > > Cheers, Manav > >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >> Wednesday, May 20, 2009 9.48 PM To: idr Subject: [Idr] Requested >> number of paths enhancement for add-paths >> >> >> >> Hi, >> >> I am proposing the below enhancement to add-paths document: >> >> Thx, R. >> >> >> 5. ADD-PATH Capability >> >> The ADD-PATH Capability is a new BGP capability [RFC3392]. The >> Capability Code for this capability is specified in the IANA >> Considerations section of this document. The Capability Length >> field of this capability is variable. The Capability Value field >> consists of one or more of the following tuples: >> >> >> +------------------------------------------------+ | Address Family >> Identifier (2 octets) | >> +------------------------------------------------+ | Subsequent >> Address Family Identifier (1 octet) | >> +------------------------------------------------+ | Send/Receive >> (1 octet) | >> +------------------------------------------------+ | Requested >> Number of Paths (1 octet) | >> +------------------------------------------------+ >> >> >> The meaning and use of the fields are as follows: >> >> Address Family Identifier (AFI): >> >> This field is the same as the one used in [RFC4760]. >> >> Subsequent Address Family Identifier (SAFI): >> >> This field is the same as the one used in [RFC4760]. >> >> Send/Receive: >> >> This field indicates whether the sender is (a) willing to receive >> multiple paths from its peer (value 1), (b) would like to send >> multiple paths to its peer (value 2), or (c) both (value 3) for the >> . Requested number of Paths: This field indicates >> maximum number of paths bgp speaker is willing to receive from it's >> peer for given AFI/SAFI. If Send/Receive field has the value of 2 >> the value of this field should be 0. *** >> >> Justification to go to 6. Operation section: The ability to signal >> how many paths bgp speaker has requested to be received has a >> significant operational advantage. As different routers have >> different roles in the network they need different number of paths >> to realize their application. As example ASBR willing to provide >> backup as well as load balancing may need more bgp paths then a P >> router just interested in backup application. >> >> Configuring all of those specific per peer information on for >> example a route reflector for hundreds of peers may result in >> configuration overhead and provisioning errors which can be easily >> avoided by the above extension. >> >> From the bgp speaker perspective such number can be considered just >> as a hint. An implementation may decide to overwrite it and to not >> comply with it. >> >> >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> > From manav@alcatel-lucent.com Wed May 20 17:59:54 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805E73A69FD for ; Wed, 20 May 2009 17:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.096 X-Spam-Level: X-Spam-Status: No, score=-4.096 tagged_above=-999 required=5 tests=[AWL=-1.847, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 762v6-tdcMQz for ; Wed, 20 May 2009 17:59:53 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 8BA483A69A7 for ; Wed, 20 May 2009 17:59:52 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4L11SgJ019705 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 May 2009 03:01:29 +0200 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 21 May 2009 03:01:28 +0200 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 21 May 2009 06:29:48 +0530 From: "Bhatia, Manav (Manav)" To: "robert@raszuk.net" Date: Thu, 21 May 2009 06:29:47 +0530 Thread-Topic: [Idr] Requested number of paths enhancement for add-paths Thread-Index: AcnZocqoI5seZS7qQQyn8dvajeHk8wADLnYA Message-ID: <7C362EEF9C7896468B36C9B79200D835036080F9C8@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4A142D28.4000806@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080F9C2@INBANSXCHMBSA1.in.alcatel-lucent.com> <4A14908B.90701@raszuk.net> In-Reply-To: <4A14908B.90701@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 00:59:54 -0000 Hi Robert, I am not suggesting anything; I am merely trying to understand the issue. Assume I have 3 paths to reach X : Path1 : as_path {A1, B, C} Path2 : as_path {A2, B, C} Path2 : as_path {A3, B, C}=20 An AS is load balancing X across these three paths. I cant understand how a= n AS can advertise its reachability using only a subset of these routes. Wo= uldn't all the downstream peers need to know all the AS details for their l= oop prevention algorithm to work? BGP peers in IXes would also btw need to know all the routes. Cheers, Manav > -----Original Message----- > From: Robert Raszuk [mailto:robert@raszuk.net]=20 > Sent: Thursday, May 21, 2009 4.52 AM > To: Bhatia, Manav (Manav) > Cc: idr > Subject: Re: [Idr] Requested number of paths enhancement for add-paths >=20 > Hi Bhatia, >=20 > > On what basis would the sender decide the subset of routes it needs > > to advertise? >=20 > On the basis of implementing ordered path list or on the basis of=20 > building group-best sets. >=20 > Are you suggesting that add-paths draft should always send=20 > all paths it=20 > has for a given net ? If so let's make sure that such point=20 > of view is=20 > reflected in the specification. >=20 > > If you're doing ECMP then wouldn't you need to > > advertise *all* the information that you have? >=20 > From the point of view of large networks I doubt seriously that even=20 > for ECMP (or unequal cost multi path for tunneled core) you=20 > need as many=20 > paths as number of your peering points to other transit ISPs. That=20 > number can be clearly in tens today. >=20 > Cheers, > R. >=20 From robert@raszuk.net Thu May 21 01:23:44 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D2E3A683B for ; Thu, 21 May 2009 01:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnueqF2SE-8m for ; Thu, 21 May 2009 01:23:43 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id D877D3A67B7 for ; Thu, 21 May 2009 01:23:42 -0700 (PDT) Received: (qmail 786 invoked by uid 399); 21 May 2009 08:25:20 -0000 Received: from unknown (HELO ?192.168.1.160?) (83.24.52.135) by mail37.opentransfer.com with SMTP; 21 May 2009 08:25:20 -0000 Message-ID: <4A150FE8.2020904@raszuk.net> Date: Thu, 21 May 2009 01:25:12 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4A142D28.4000806@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080F9C2@INBANSXCHMBSA1.in.alcatel-lucent.com> <4A14908B.90701@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080F9C8@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D835036080F9C8@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 08:23:44 -0000 Hi, My first observation is that we are talking about different things ... I was focusing on intra-domain route distribution from route reflector to it's clients and allowing 100s of clients to inform route reflector on their application needs wrt numer of paths they would like to receive. That would be on the IBGP sessions only. For clarity we could add to my proposed text that the requested number of paths applies to IBGP sessions. For EBGP for the time being it should be set to 0 (all paths) till an add-paths EBGP application rfc recommends otherwise. Your point is between ASes over EBGP sessions. I think this is totally different application for which there is no even application draft using add-path. Sending inactive paths may be fatal. Sending subset of them may be dangerous as well if peer's inbound policy can drop some of them. How to mark them which are active/best and which are not is not defined today. I think this application requires it's own discussion. Some scenarios have been already very well described and presented by Brian Dickson in the past. And that could be very good starting point for specification of this application. Cheers, R. > Hi Robert, > > I am not suggesting anything; I am merely trying to understand the issue. > > Assume I have 3 paths to reach X : > > Path1 : as_path {A1, B, C} > Path2 : as_path {A2, B, C} > Path2 : as_path {A3, B, C} > > An AS is load balancing X across these three paths. I cant understand how an AS can advertise its reachability using only a subset of these routes. Wouldn't all the downstream peers need to know all the AS details for their loop prevention algorithm to work? > > BGP peers in IXes would also btw need to know all the routes. > > Cheers, Manav > >> -----Original Message----- >> From: Robert Raszuk [mailto:robert@raszuk.net] >> Sent: Thursday, May 21, 2009 4.52 AM >> To: Bhatia, Manav (Manav) >> Cc: idr >> Subject: Re: [Idr] Requested number of paths enhancement for add-paths >> >> Hi Bhatia, >> >> > On what basis would the sender decide the subset of routes it needs >> > to advertise? >> >> On the basis of implementing ordered path list or on the basis of >> building group-best sets. >> >> Are you suggesting that add-paths draft should always send >> all paths it >> has for a given net ? If so let's make sure that such point >> of view is >> reflected in the specification. >> >> > If you're doing ECMP then wouldn't you need to >> > advertise *all* the information that you have? >> >> From the point of view of large networks I doubt seriously that even >> for ECMP (or unequal cost multi path for tunneled core) you >> need as many >> paths as number of your peering points to other transit ISPs. That >> number can be clearly in tens today. >> >> Cheers, >> R. >> > > From dongjie_dj@huawei.com Thu May 21 03:06:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD40528C116 for ; Thu, 21 May 2009 03:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeOoWiyIN1ls for ; Thu, 21 May 2009 03:06:15 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 80AF128C13A for ; Thu, 21 May 2009 03:06:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJZ00LVTNNAHY@szxga04-in.huawei.com> for idr@ietf.org; Thu, 21 May 2009 17:57:10 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJZ00IS9NNA1Z@szxga04-in.huawei.com> for idr@ietf.org; Thu, 21 May 2009 17:57:10 +0800 (CST) Received: from d65110 ([10.111.12.97]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJZ00IZPNN90X@szxml06-in.huawei.com> for idr@ietf.org; Thu, 21 May 2009 17:57:10 +0800 (CST) Date: Thu, 21 May 2009 17:57:09 +0800 From: Jie Dong In-reply-to: <4A150FE8.2020904@raszuk.net> To: robert@raszuk.net, "'Bhatia, Manav (Manav)'" Message-id: <000001c9d9fa$820a1500$610c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZ7be/m1RaRsvaQ4WX8mgEgIQQjwACH9Qw Cc: 'idr' Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 10:06:15 -0000 Hi Robert, I agree with you that different specifications should be made for EBGP and IBGP sessions, and here are some suggestions: For IBGP session: In order to make all IBGP speakers in one AS obtain consistent routing information, after considering all of the requested number from IBGP peers, the advertiser should determine the number of routes sent to each IBGP peer, and in common case it should send the same number of routes to all its peers. For EBGP session: The advertiser should honor the requested number #n from its peer, and send its best #n routes to its peers. It may send different number of routes to different EBGP peers. Best regards, Jie > -----Original Message----- > > I was focusing on intra-domain route distribution from route reflector > to it's clients and allowing 100s of clients to inform route reflector > on their application needs wrt numer of paths they would like to > receive. That would be on the IBGP sessions only. > > For clarity we could add to my proposed text that the requested number > of paths applies to IBGP sessions. For EBGP for the time being it should > be set to 0 (all paths) till an add-paths EBGP application rfc > recommends otherwise. > > Your point is between ASes over EBGP sessions. I think this is totally > different application for which there is no even application draft using > add-path. Sending inactive paths may be fatal. Sending subset of them > may be dangerous as well if peer's inbound policy can drop some of them. > How to mark them which are active/best and which are not is not > defined today. I think this application requires it's own discussion. > Some scenarios have been already very well described and presented by > Brian Dickson in the past. And that could be very good starting point > for specification of this application. > Cheers, > R. > > > > Hi Robert, > > > > I am not suggesting anything; I am merely trying to understand the issue. > > > > Assume I have 3 paths to reach X : > > > > Path1 : as_path {A1, B, C} > > Path2 : as_path {A2, B, C} > > Path2 : as_path {A3, B, C} > > > > An AS is load balancing X across these three paths. I cant understand how > an AS can advertise its reachability using only a subset of these routes. > Wouldn't all the downstream peers need to know all the AS details for their > loop prevention algorithm to work? > > > > BGP peers in IXes would also btw need to know all the routes. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Robert Raszuk [mailto:robert@raszuk.net] > >> Sent: Thursday, May 21, 2009 4.52 AM > >> To: Bhatia, Manav (Manav) > >> Cc: idr > >> Subject: Re: [Idr] Requested number of paths enhancement for add-paths > >> > >> Hi Bhatia, > >> > >> > On what basis would the sender decide the subset of routes it needs > >> > to advertise? > >> > >> On the basis of implementing ordered path list or on the basis of > >> building group-best sets. > >> > >> Are you suggesting that add-paths draft should always send > >> all paths it > >> has for a given net ? If so let's make sure that such point > >> of view is > >> reflected in the specification. > >> > >> > If you're doing ECMP then wouldn't you need to > >> > advertise *all* the information that you have? > >> > >> From the point of view of large networks I doubt seriously that even > >> for ECMP (or unequal cost multi path for tunneled core) you > >> need as many > >> paths as number of your peering points to other transit ISPs. That > >> number can be clearly in tens today. > >> > >> Cheers, > >> R. > >> > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From manav@alcatel-lucent.com Thu May 21 05:04:41 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A333A6C74 for ; Thu, 21 May 2009 05:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDZWA8eFKmbC for ; Thu, 21 May 2009 05:04:41 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id B22DC3A6AF1 for ; Thu, 21 May 2009 05:04:39 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4LC6BqP010173 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 May 2009 14:06:16 +0200 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 21 May 2009 14:06:15 +0200 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 21 May 2009 17:23:45 +0530 From: "Bhatia, Manav (Manav)" To: "robert@raszuk.net" Date: Thu, 21 May 2009 17:23:44 +0530 Thread-Topic: [Idr] Requested number of paths enhancement for add-paths Thread-Index: AcnZ7dBAs/Pnil1QQbeAhf2ZftYvVgAG1/Sw Message-ID: <7C362EEF9C7896468B36C9B79200D835036080FD3B@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4A142D28.4000806@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080F9C2@INBANSXCHMBSA1.in.alcatel-lucent.com> <4A14908B.90701@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080F9C8@INBANSXCHMBSA1.in.alcatel-lucent.com> <4A150FE8.2020904@raszuk.net> In-Reply-To: <4A150FE8.2020904@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 12:04:41 -0000 Hi, > My first observation is that we are talking about different things ... >=20 > I was focusing on intra-domain route distribution from route=20 > reflector=20 > to it's clients and allowing 100s of clients to inform route=20 > reflector=20 > on their application needs wrt numer of paths they would like to=20 > receive. That would be on the IBGP sessions only. Are you suggesting that each client could potentially give a different numb= er to the RR based on the application its running? This sounds a trifle odd= to me. How would a client know that it can solve all cases of route oscill= ation if it receives "n" routes from the RR? This also means that the view = inside the AS is inconsistent with some routers having more information tha= n the others. When the RR advertises the subset of routes, does it indicate the ones that= have been installed in the FIB? What if it installs 3 routes and a peer re= quests for just 2?=20 And I agree that EBGP is a different ball game altogether and should not be= mixed with IBGP. Cheers, Manav > For clarity we could add to my proposed text that the=20 > requested number=20 > of paths applies to IBGP sessions. For EBGP for the time=20 > being it should=20 > be set to 0 (all paths) till an add-paths EBGP application rfc=20 > recommends otherwise. >=20 > Your point is between ASes over EBGP sessions. I think this=20 > is totally=20 > different application for which there is no even application=20 > draft using=20 > add-path. Sending inactive paths may be fatal. Sending subset of them=20 > may be dangerous as well if peer's inbound policy can drop=20 > some of them.=20 > How to mark them which are active/best and which are not is not=20 > defined today. I think this application requires it's own discussion.=20 > Some scenarios have been already very well described and presented by=20 > Brian Dickson in the past. And that could be very good starting point=20 > for specification of this application. >=20 > Cheers, > R. >=20 >=20 > > Hi Robert, > >=20 > > I am not suggesting anything; I am merely trying to=20 > understand the issue. > >=20 > > Assume I have 3 paths to reach X : > >=20 > > Path1 : as_path {A1, B, C} > > Path2 : as_path {A2, B, C} > > Path2 : as_path {A3, B, C}=20 > >=20 > > An AS is load balancing X across these three paths. I cant=20 > understand how an AS can advertise its reachability using=20 > only a subset of these routes. Wouldn't all the downstream=20 > peers need to know all the AS details for their loop=20 > prevention algorithm to work? > >=20 > > BGP peers in IXes would also btw need to know all the routes. > >=20 > > Cheers, Manav From robert@raszuk.net Thu May 21 08:30:22 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973AB28C11B for ; Thu, 21 May 2009 08:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFNG0-c7aHmy for ; Thu, 21 May 2009 08:30:21 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id A7FFB28C0DE for ; Thu, 21 May 2009 08:30:21 -0700 (PDT) Received: (qmail 12344 invoked by uid 399); 21 May 2009 15:31:58 -0000 Received: from unknown (HELO ?192.168.1.160?) (83.24.52.135) by mail37.opentransfer.com with SMTP; 21 May 2009 15:31:58 -0000 Message-ID: <4A1573E6.1040402@raszuk.net> Date: Thu, 21 May 2009 08:31:50 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4A142D28.4000806@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080F9C2@INBANSXCHMBSA1.in.alcatel-lucent.com> <4A14908B.90701@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080F9C8@INBANSXCHMBSA1.in.alcatel-lucent.com> <4A150FE8.2020904@raszuk.net> <7C362EEF9C7896468B36C9B79200D835036080FD3B@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D835036080FD3B@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] Requested number of paths enhancement for add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 15:30:22 -0000 Hi, So let's focus on the IBGP case ... > Are you suggesting that each client could potentially give a > different number to the RR based on the application its running? Yes. > This sounds a trifle odd to me. Why ? Imagine network running some form of internal tunneling for example MPLS. Some of it's ASBRs/PEs are new and upgraded are running mission critical applications and would like to offer the service of fast bgp connectivity restoration by pre-programing their forwarding with additional bgp backup exit point. What is wrong with this that some PEs will have two paths to the remote ASBRs and some will not ? Remember there are LSPs (LDP or RSVP-TE) or IP tunnels (exemple: GRE) to avoid any intra-domain looping issues. > How would a client know that it can solve > all cases of route oscillation if it receives "n" routes from the RR? For that application if service provider is interested in solving he may ask for all external paths. > This also means that the view inside the AS is inconsistent with some > routers having more information than the others. How otherwise you would propose to realistically deploy this technology ? If you enable it on one or few routers those will get as many paths as RR will give them while other clients of such RR not supporting add-paths will still get only the best path. I have seem many proposal in the IDR which were rejected just due difficulty to provide gradual deployment. Would that be the next example of it ? > When the RR advertises the subset of routes, does it indicate the > ones that have been installed in the FIB? What if it installs 3 > routes and a peer requests for just 2? In any case I think this new functionality does require a very good planning and consideration on the type of network this would be used in. It is very clear that an implementation must provide the limiting tools not to send all paths. It could be as suggested via client to RR information then as commented by Jie RR would find the min common denominator or it should be configured manually on the RR on a per SAFI basis. Thinking more on this perhaps such configuration on the RR on a per SAFI basis is the equally good choice of the solution reg the decision on how many paths to send to the clients. Cheers, R. From root@core3.amsl.com Tue May 26 17:00:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CBE9B3A6B5A; Tue, 26 May 2009 17:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090527000001.CBE9B3A6B5A@core3.amsl.com> Date: Tue, 26 May 2009 17:00:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-flow-spec-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 00:00:01 -0000 --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 : Dissemination of flow specification rules Author(s) : P. Roque Marques, et al. Filename : draft-ietf-idr-flow-spec-09.txt Pages : 24 Date : 2009-05-26 This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-flow-spec-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-26165038.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Wed May 27 07:53:59 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 25D263A6A15; Wed, 27 May 2009 07:53:59 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090527145359.25D263A6A15@core3.amsl.com> Date: Wed, 27 May 2009 07:53:59 -0700 (PDT) Cc: idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: [Idr] Protocol Action: 'Dissemination of flow specification rules' to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 14:53:59 -0000 The IESG has approved the following document: - 'Dissemination of flow specification rules ' as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-09.txt Technical Summary This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. Working Group Summary Consensus on the technology was not an issue. There was an IPR disclosure that occurred after WG LC. Document Quality There are multiple, interoperable implementations. There were no LC comments during WG LC although the technology and draft have been known, discussed and available for many years. See:draft-raszuk-idr-flow-spec-impl-00 Personnel Yakov Rekhter is the Document Shepherd for this document. Dave Ward is the Area Director. RFC editor's note Please change Robert Raszuk's email address to be robert@raszuk.net. IANA Note Future assignments beyond what is specified in the draft are to be made using either the Standards Action process defined in [RFC2434], the Early IANA Allocation process defined in [RFC4020], or the "First Come First Served" policy defined in [RFC2434]. From robert@raszuk.net Wed May 27 16:34:28 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9853A7183 for ; Wed, 27 May 2009 16:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEC4m6R1T8+3 for ; Wed, 27 May 2009 16:34:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2B2703A6F74 for ; Wed, 27 May 2009 16:34:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,261,1241395200"; d="scan'208";a="165044343" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 27 May 2009 23:36:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4RNaAFw032111 for ; Wed, 27 May 2009 16:36:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4RNaAIf017091 for ; Wed, 27 May 2009 23:36:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 16:36:10 -0700 Received: from [10.32.198.52] ([10.32.198.52]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 16:36:10 -0700 Message-ID: <4A1DCE61.3080901@raszuk.net> Date: Wed, 27 May 2009 16:36:01 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: idr@ietf.org References: <09A656CD8EE63F42982A7964FEEDB17D02168669@USDALSMBS05.ad3.ad.alcatel.com> In-Reply-To: <09A656CD8EE63F42982A7964FEEDB17D02168669@USDALSMBS05.ad3.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2009 23:36:10.0636 (UTC) FILETIME=[EA68DCC0:01C9DF23] Authentication-Results: sj-dkim-3; header.From=robert@raszuk.net; dkim=neutral Subject: [Idr] Transport Instance BGP X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 23:34:29 -0000 FYI ... A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transport Instance BGP Author(s) : R. Raszuk, K. Patel Filename : draft-raszuk-ti-bgp-00.txt Pages : 13 Date : 2009-05-27 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-raszuk-ti-bgp-00.txt Abstract: BGP4 protocol is a well established single standard of an inter- domain Internet routing and non Internet routing information distribution today. For many applications it is a lso the protocol of choice to disseminate various application based information intra- domain. It's popularity and it's wide use has been effectively provided by it's reliable transport, session protection as well as loop free build in mechanism. It has been observed in both intra-domain as well as inter-domain applications that reliable information distribution is an extremely desired tool for many services. Introduction of Multiprotocol Extensions to BGP even further attracted various sorts of new information to be carried over BGP4. The observation proves that amount and nature of information carried by BGP increases and diverges from the original goal of interconnection for IP Internet Autonomous Systems at a rather fast pace. This draft proposes BGP to divide information into two broad categories: Internet routing critical and non Internet routing critical that would also include information carried by BGP which is not related directly to routing. For the purpose of this document we will refer to the latter case as second BGP instance. This draft proposes that the current BGP infrastructure will continue to be used to disseminate Internet routing related information while non routing information or private routing data is recommended to be carried by independent transport instance BGP.