From jgs@juniper.net Thu Jun 2 12:18:27 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917B7E06BC for ; Thu, 2 Jun 2011 12:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5KX4jWpKvas for ; Thu, 2 Jun 2011 12:18:26 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4F127E078F for ; Thu, 2 Jun 2011 12:18:26 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTefiAYhzUBbPbwdQrHwHiDo63YVm4gZ0@postini.com; Thu, 02 Jun 2011 12:18:26 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 2 Jun 2011 12:16:01 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 2 Jun 2011 12:15:59 -0700 Thread-Topic: draft-keyur-bgp-enhanced-route-refresh as WG document Thread-Index: AcwhWYIvAqvlIAOoQ4iWz8lyIQ0HWw== Message-ID: 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 Subject: [Idr] draft-keyur-bgp-enhanced-route-refresh as WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:18:27 -0000 Folks, draft-keyur-bgp-enhanced-route-refresh is accepted as an IDR working group = document. Authors, please resubmit as draft-ietf-idr-bgp-enhanced-route-re= fresh-00. The chairs will consult with the AD regarding adding this to our charter. --John= From jgs@juniper.net Thu Jun 2 12:20:58 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74083E0860 for ; Thu, 2 Jun 2011 12:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgskkAH6cfQw for ; Thu, 2 Jun 2011 12:20:58 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id A95EAE0853 for ; Thu, 2 Jun 2011 12:20:57 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTefimImf2YIGp2QLCpDtDWo6fIK08OWk@postini.com; Thu, 02 Jun 2011 12:20:57 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 2 Jun 2011 12:17:50 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 2 Jun 2011 12:17:49 -0700 Thread-Topic: draft-ymbk-bgp-extended-messages as WG document Thread-Index: AcwhWcNifOM75+kKQ06K9d795E9AFA== Message-ID: <79308F5D-655D-4E25-B35C-4F6B7440B043@juniper.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 Subject: [Idr] draft-ymbk-bgp-extended-messages as WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:20:58 -0000 Folks, draft-ymbk-bgp-extended-messages is accepted as an IDR working group docume= nt. Authors, please resubmit as draft-ietf-idr-bgp-extended-messages-00. The chairs will consult with the AD regarding adding this to our charter. --John= From jgs@juniper.net Thu Jun 2 12:24:23 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B6DE0853 for ; Thu, 2 Jun 2011 12:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8F0zQ1oRLSD for ; Thu, 2 Jun 2011 12:24:23 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 17B44E0860 for ; Thu, 2 Jun 2011 12:24:23 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTefjZi/zgrqqbN6qcYVhirb64lAUMJgW@postini.com; Thu, 02 Jun 2011 12:24:23 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 2 Jun 2011 12:22:50 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 2 Jun 2011 12:22:49 -0700 Thread-Topic: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 Thread-Index: AcwhWnaCG0dfIIXIRtGqX/0k54hlMQ== Message-ID: <297696E4-489F-41CA-BE46-52659A523518@juniper.net> References: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.net> In-Reply-To: <49C00B6B-0628-4E0B-9CC7-87994631560C@juniper.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 Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:24:23 -0000 The WGLC has concluded. We will send the draft to the IESG for publication= as an RFC after consulting with the AD. Thanks, --John On May 2, 2011, at 5:36 PM, John Scudder wrote: > Folks, >=20 > This is to start a (new) working group last call for draft-ietf-idr-depre= cate-as-sets-04. Please send comments by May 17, 2011. >=20 > http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04 >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Thu Jun 2 13:34:11 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8996FE0899 for ; Thu, 2 Jun 2011 13:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23b3fc6FXLXf for ; Thu, 2 Jun 2011 13:34:10 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE69E0865 for ; Thu, 2 Jun 2011 13:34:10 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTefzwZltSu2K+eZWV4mY2gWT0mkYy269@postini.com; Thu, 02 Jun 2011 13:34:10 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 2 Jun 2011 13:33:05 -0700 From: John Scudder To: "raszuk@cisco.com" Date: Thu, 2 Jun 2011 13:33:03 -0700 Thread-Topic: [Idr] Dissemination of Flow Specification Rules for IPv6 Thread-Index: AcwhZEZFzu7CoOf+T2y9Il4UvKNSTw== Message-ID: References: <4D94823E.9070806@cisco.com> In-Reply-To: <4D94823E.9070806@cisco.com> 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 Cc: "idr@ietf.org List" Subject: Re: [Idr] Dissemination of Flow Specification Rules for IPv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:34:11 -0000 Folks, This is accepted as an IDR working group document. Authors, please resubmi= t as draft-ietf-idr-flow-spec-v6-00. The chairs will consult with the AD regarding adding this to our charter. --John On Mar 31, 2011, at 9:31 AM, Robert Raszuk wrote: >=20 > Authors of "Dissemination of Flow Specification Rules for IPv6" draft=20 > document would like to propose the adoption of this work as the IDR WG it= em. >=20 > Ref: > http://tools.ietf.org/html/draft-raszuk-idr-flow-spec-v6-01 >=20 > Rgs, > R. Raszuk > B. Pithawala > D. McPherson > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Thu Jun 2 22:36:09 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493CAE06FD; Thu, 2 Jun 2011 22:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kis7Abu+wGo5; Thu, 2 Jun 2011 22:36:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E4DE0682; Thu, 2 Jun 2011 22:36:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110603053608.32673.79743.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 22:36:08 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-dynamic-cap-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 05:36:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Dynamic Capability for BGP-4 Author(s) : Enke Chen Srihari R. Sangli Filename : draft-ietf-idr-dynamic-cap-13.txt Pages : 7 Date : 2011-06-02 This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-13.txt From jgs@juniper.net Fri Jun 3 08:26:21 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E427E0779 for ; Fri, 3 Jun 2011 08:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVsuG5OXEr2N for ; Fri, 3 Jun 2011 08:26:20 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 392E7E077F for ; Fri, 3 Jun 2011 08:26:20 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTej8/IALNC+3Vek/xDmBNMJCVjWj28H0@postini.com; Fri, 03 Jun 2011 08:26:20 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 3 Jun 2011 08:24:50 -0700 From: John Scudder To: Jie Dong Date: Fri, 3 Jun 2011 08:24:49 -0700 Thread-Topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-Index: AcwiAmEMVky/dfI1RK+uYTuuX26ixw== Message-ID: <694F8892-77D3-47C5-AFCB-F609F15D87C2@juniper.net> References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> 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 Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:26:21 -0000 Folks, This is accepted as an IDR working group document. Authors, please resubmi= t as draft-ietf-idr-af-specific-rt-constrain-00. The chairs will consult with the AD regarding adding this to our charter. --John On Mar 31, 2011, at 11:54 AM, Jie Dong wrote: > Dear all,=20 >=20 > Authors of "IPv6 AF Extensions for Route Target Distribution" would like = to propose to adopt this draft as IDR WG document. >=20 > The draft could be found at:=20 > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 >=20 >=20 > Best regards, > Keyur Patel > Robert Raszuk > Martine Djernaes > Jie Dong > Mach Chen >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Fri Jun 3 08:27:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF66EE0786 for ; Fri, 3 Jun 2011 08:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvGNUuxnGBzT for ; Fri, 3 Jun 2011 08:27:45 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4BE0780 for ; Fri, 3 Jun 2011 08:27:19 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTej9V5S6DHWTL7y7tCu8P/PaaPgq7oic@postini.com; Fri, 03 Jun 2011 08:27:19 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 3 Jun 2011 08:26:04 -0700 From: John Scudder To: "idr@ietf.org List" Date: Fri, 3 Jun 2011 08:26:03 -0700 Thread-Topic: New WG documents Thread-Index: AcwiAo1KseUrBO3qS6qxU57SEzw4pQ== Message-ID: <6F9C2097-73DC-44EC-9511-53CF6F3351B1@juniper.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 Subject: [Idr] New WG documents X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:27:45 -0000 Folks, FYI there seems to be some delay in the new WG draft approval process. I h= ave a ticket open with the Secretariat to investigate. FYI, this is the re= ason you're not seeing new WG -00 drafts for those that have recently been = accepted. --John= From Internet-Drafts@ietf.org Fri Jun 3 14:30:02 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6987E07EB; Fri, 3 Jun 2011 14:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrNLzZVlInDf; Fri, 3 Jun 2011 14:30:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7111CE07D4; Fri, 3 Jun 2011 14:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110603213002.3788.66791.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2011 14:30:02 -0700 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-optimal-route-reflection-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 21:30:03 -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 : BGP Optimal Route Reflection (BGP-ORR) Author(s) : R. Raszuk, et al Filename : draft-ietf-idr-bgp-optimal-route-reflection-00.txt Pages : 19 Date : 2011-06-03 [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-optimal-route-reflection-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-bgp-optimal-route-reflection-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-06-03142411.I-D@ietf.org> --NextPart-- From raszuk@cisco.com Sat Jun 4 15:51:44 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7434411E807B for ; Sat, 4 Jun 2011 15:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWsHHhkMrnxZ for ; Sat, 4 Jun 2011 15:51:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id A37C511E8071 for ; Sat, 4 Jun 2011 15:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=5548; q=dns/txt; s=iport; t=1307227903; x=1308437503; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=1yZgvFAreNoOdHYBD2RbbVYNMVS29oRNxP3ee3Lewnw=; b=BLbBADpt1RZKdfadJZrPOVqKVUPc1rdT2HVsDfqRJ4s6PBuWNltcQros 5WBdYlnDzVRAM98z/MjQY8v33ktOgQqLanfnZWFoODgbuot/DKiHsTERh Qzzu2VGeHQI7VYkVYRLqntk2HFASGo01dHfGzFgZ86Oyy7Z+W3bkFSTcL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALO26k2rRDoH/2dsb2JhbABTpkZ3qR6CfA8BmWOGIQSQeYRIinQ X-IronPort-AV: E=Sophos;i="4.65,321,1304294400"; d="scan'208";a="459843359" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 04 Jun 2011 22:51:43 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p54MpgP0014886 for ; Sat, 4 Jun 2011 22:51:42 GMT Message-ID: <4DEAB70D.10403@cisco.com> Date: Sun, 05 Jun 2011 00:51:57 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "idr@ietf.org List" References: <20110604181137.3308.46470.idtracker@ietfa.amsl.com> In-Reply-To: <20110604181137.3308.46470.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 22:51:44 -0000 Hi, Attracted by the title I could not resit to read this draft. Here are some of the comments and questions I have regarding the document. * Up front to make it very clear for all readers can authors explicitly confirm that the applicability of this draft is only limited to networks which use some form of tunneling (for example: MPLS) between each PE and ASBRs ? * The idea of community based route selection on RRs is nothing new. Using RT extended community as well as RT Constrain while does automates the preference push from PE to RR to limit number of paths to be received. However if also comes along with the following issues: - It does it in pure static way putting all burden of what can be automated into the operator's NOC. Note that all information required for optimal path selection is already present on RR without any need for operational configuration burden today. - The networks topologies change dynamically which will not be reflected in the static RT based preference. - Addition and deletion of new ASBR both planned and unplanned require full reconfiguration of each PE to get to the same level of BGP path redundancy reception. - Addition and deletion of new service POP both planned and unplanned require full reconfiguration of each PE to get to the same level of BGP path redundancy reception. - POPs which do not have local exit ASBRs and which do not leak next hops from core to POP area in the IGP even if given opportunity to receive _all_ external paths still have no visibility into the closet exit ASBR in the domain as ABRs would typically depending on the IGP selection and area type shield them from domain wide flooding information. Therefor those PEs will still remain selecting random paths unless the proposal would also include static best path selection on such PEs based on RT. * The draft says: We make the assumption that complete Internet routing information is available at every ASBR. If the local ASBR does not have reachibility to the relevant prefixes (or the ASBR itself is not available), traffic should use the closest (in terms of IGP metric) egress. It would be interesting to see under what network conditions one could assure that that every ASBR in the network contains complete Internet routing. Then I would like to see prove on how using static RT mapping to one's preference of some day assures reception and selection of paths which could be categorized as "closest (in terms of IGP metric) egress". Provided example of 3 ASBRs located on three continents of the world is rather unreal considering today's network topologies where number of ASBRs or IX interconnects very often reaches much larger numbers. * The title of the draft should reflect that the proposal does not provide, a solution for "optimal" route reflection. The draft describes a solution for "operator's statically configured ASBR path preferences". Those two are quite dis-joined solutions. While perhaps under some scenarios the end result may be the same at a given point of time there is no guarantee that such result will stay as such during day to day network operation. * RT Constrain as proposed, implemented and deployed today has been designed to express a VPN membership rules as an base object. While there were some attempts to further divide this to be on per AFI/SAFI basis RT Constrain authors came to the conclusion that those attempts have no practical justification. In this proposal use of RT constrain filtering would however result in the same exit ASBR preference to be applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It is already well known fact in operation today that optimal/closest exit preferences for IPv4 unicast do not match in many networks the optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs. It would be interesting how authors of the proposed draft are going to address this point going forward. *** Now let me take a moment to provide few points on number of advantages of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 as compared with the above document: * IDR WG draft does not require any manual static configuration of path preferences - all required information is already present today on the RR and can be readily used. * IDR WG draft can use add-paths to send more then best optimal path from RR to the RR client - per clients preference * IDR WG draft dynamically recalculates optimal/closest IGP metric exist point or points for each client and group of clients when ASBR add/withdraw BGP routes or when IGP topology changes * IDR WG draft provides ways to dynamically group clients based on their common POP location / IGP area without any operator's configuration burden on RR * IDR WG draft works equally well in normal IPv4/IPv6 networks as well as with some form of tunneled networks without putting any requirement on forwarding paradigm selection in the network * It works in the same way for any AFI/SAFI and independently guarantees calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6 paths as well as their distribution to the clients. * IDR WG document provides ability for virtual RR placement in any IGP network node location without any physical reconnection required. Such provision is not addressed in the above document. Best regards, R. From jeff.tantsura@ericsson.com Sat Jun 4 19:05:18 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FF121F84B1 for ; Sat, 4 Jun 2011 19:05:18 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6qi-cPpxbnV for ; Sat, 4 Jun 2011 19:05:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 20F2E21F84B0 for ; Sat, 4 Jun 2011 19:05:17 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5525FBW010878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Jun 2011 21:05:15 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sat, 4 Jun 2011 22:05:14 -0400 From: Jeff Tantsura To: "raszuk@cisco.com" Date: Sat, 4 Jun 2011 22:05:08 -0400 Thread-Topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Thread-Index: AcwjJQF6+PoZe9BiTPO0p4669IqsEg== Message-ID: <94E61C27-F386-4EA7-B1CD-60A7619D3874@ericsson.com> References: <20110604181137.3308.46470.idtracker@ietfa.amsl.com> <4DEAB70D.10403@cisco.com> In-Reply-To: <4DEAB70D.10403@cisco.com> 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 Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 02:05:19 -0000 +1 Regards, Jeff On Jun 4, 2011, at 15:51, "Robert Raszuk" wrote: > Hi, >=20 > Attracted by the title I could not resit to read this draft. Here are=20 > some of the comments and questions I have regarding the document. >=20 > * Up front to make it very clear for all readers can authors explicitly=20 > confirm that the applicability of this draft is only limited to networks= =20 > which use some form of tunneling (for example: MPLS) between each PE and= =20 > ASBRs ? >=20 > * The idea of community based route selection on RRs is nothing new.=20 > Using RT extended community as well as RT Constrain while does automates= =20 > the preference push from PE to RR to limit number of paths to be=20 > received. However if also comes along with the following issues: >=20 > - It does it in pure static way putting all burden of what can be=20 > automated into the operator's NOC. Note that all information required=20 > for optimal path selection is already present on RR without any need for= =20 > operational configuration burden today. >=20 > - The networks topologies change dynamically which will not be=20 > reflected in the static RT based preference. >=20 > - Addition and deletion of new ASBR both planned and unplanned require=20 > full reconfiguration of each PE to get to the same level of BGP path=20 > redundancy reception. >=20 > - Addition and deletion of new service POP both planned and unplanned=20 > require full reconfiguration of each PE to get to the same level of BGP=20 > path redundancy reception. >=20 > - POPs which do not have local exit ASBRs and which do not leak next=20 > hops from core to POP area in the IGP even if given opportunity to=20 > receive _all_ external paths still have no visibility into the closet=20 > exit ASBR in the domain as ABRs would typically depending on the IGP=20 > selection and area type shield them from domain wide flooding=20 > information. Therefor those PEs will still remain selecting random paths= =20 > unless the proposal would also include static best path selection on=20 > such PEs based on RT. >=20 > * The draft says: >=20 > We make the assumption that complete Internet routing > information is available at every ASBR. If the local ASBR does not > have reachibility to the relevant prefixes (or the ASBR itself is not > available), traffic should use the closest (in terms of IGP metric) > egress. >=20 > It would be interesting to see under what network conditions one could=20 > assure that that every ASBR in the network contains complete Internet=20 > routing. Then I would like to see prove on how using static RT mapping=20 > to one's preference of some day assures reception and selection of paths= =20 > which could be categorized as "closest (in terms of IGP metric) egress".= =20 > Provided example of 3 ASBRs located on three continents of the world is=20 > rather unreal considering today's network topologies where number of=20 > ASBRs or IX interconnects very often reaches much larger numbers. >=20 > * The title of the draft should reflect that the proposal does not=20 > provide, a solution for "optimal" route reflection. The draft describes=20 > a solution for "operator's statically configured ASBR path preferences".= =20 > Those two are quite dis-joined solutions. While perhaps under some=20 > scenarios the end result may be the same at a given point of time there=20 > is no guarantee that such result will stay as such during day to day=20 > network operation. >=20 > * RT Constrain as proposed, implemented and deployed today has been=20 > designed to express a VPN membership rules as an base object. While=20 > there were some attempts to further divide this to be on per AFI/SAFI=20 > basis RT Constrain authors came to the conclusion that those attempts=20 > have no practical justification. In this proposal use of RT constrain=20 > filtering would however result in the same exit ASBR preference to be=20 > applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It is=20 > already well known fact in operation today that optimal/closest exit=20 > preferences for IPv4 unicast do not match in many networks the=20 > optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs.=20 > It would be interesting how authors of the proposed draft are going to=20 > address this point going forward. >=20 > *** >=20 > Now let me take a moment to provide few points on number of advantages=20 > of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 as= =20 > compared with the above document: >=20 > * IDR WG draft does not require any manual static configuration of path=20 > preferences - all required information is already present today on the=20 > RR and can be readily used. >=20 > * IDR WG draft can use add-paths to send more then best optimal path=20 > from RR to the RR client - per clients preference >=20 > * IDR WG draft dynamically recalculates optimal/closest IGP metric exist= =20 > point or points for each client and group of clients when ASBR=20 > add/withdraw BGP routes or when IGP topology changes >=20 > * IDR WG draft provides ways to dynamically group clients based on their= =20 > common POP location / IGP area without any operator's configuration=20 > burden on RR >=20 > * IDR WG draft works equally well in normal IPv4/IPv6 networks as well=20 > as with some form of tunneled networks without putting any requirement=20 > on forwarding paradigm selection in the network >=20 > * It works in the same way for any AFI/SAFI and independently guarantees= =20 > calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6=20 > paths as well as their distribution to the clients. >=20 > * IDR WG document provides ability for virtual RR placement in any IGP=20 > network node location without any physical reconnection required. Such=20 > provision is not addressed in the above document. >=20 > Best regards, > R. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From vjoseph@juniper.net Sun Jun 5 13:00:21 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D090D21F8466 for ; Sun, 5 Jun 2011 13:00:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUIp6PwjeMjD for ; Sun, 5 Jun 2011 13:00:20 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id D021121F84C6 for ; Sun, 5 Jun 2011 13:00:19 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTevgUsDWmHFd/PWTJd6wunswFdvP5Rql@postini.com; Sun, 05 Jun 2011 13:00:19 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Sun, 5 Jun 2011 12:58:15 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Jun 2011 20:58:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 5 Jun 2011 20:58:05 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996B0D@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Thread-Index: AcwjsuDJanNCP/FhSd2Ne8+PbBAdcgAAUgYQ References: From: Vinod Joseph To: X-OriginalArrivalTime: 05 Jun 2011 19:58:13.0878 (UTC) FILETIME=[E7533160:01CC23BA] Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 20:00:21 -0000 Robert, The objective of the draft is to provide closest exit routing based on = the operators preference. Let me answer each of the comments inline: > It does it in pure static way putting all burden of what can be=20 automated into the operator's NOC. Note that all information required=20 for optimal path selection is already present on RR without any need for = operational configuration burden today. Vinod# You rightly said that RT constrain and Route Targets have been = used for a while now. The idea of this draft is to ensure that existing = BGP machinery successfully used in the context of other address = families, is used for IPv4. Policy control on the list of paths needed = is indicated by the PE through the use of RT constrain, and only = prefixes/paths that match the list of RTs specified are announced by the = RR, and the PEs do the best path calculation. It is arguable that policy = control via RT constrain adds operational burden - since the use of RT = and RT constrain have been used on other address families for ages as = you mentioned. The advantage here is that the RR can be completely taken = out of the picture as far as the closest or optimal path calculation = goes. The networks topologies change dynamically which will not be=20 reflected in the static RT based preference. Vinod# Let me put it this way, an operator may prefer a list of RTs and = not just a single RT - if we assume a single RT maps to a single ASBR, = to build resiliency. The objective is clear - provide the operator with = an approach to selectively choose the best path, and also indicate a = list of affinities (list of RTs) that a PE is interested in. It is also = possible to extend the scheme where all ASBRs within a region =3D a = single RT. Therefore there is flexibility. Primarily this draft does not = (1) break the use of BGP Peer groups (2) cause network churn if there is = an IGP change, since we are not using an SPF instance per PE.=20 - Addition and deletion of new ASBR both planned and unplanned require=20 full reconfiguration of each PE to get to the same level of BGP path=20 redundancy reception. Vinod# Like I mentioned, planning for resiliency and allocation of RTs = are flexible. It is not mandatory to have a single ASBR be allotted a = single RT, multiple ASBRs may share the same RT. > POPs which do not have local exit ASBRs and which do not leak next=20 hops from core to POP area in the IGP even if given opportunity to=20 receive _all_ external paths still have no visibility into the closet=20 exit ASBR in the domain as ABRs would typically depending on the IGP=20 selection and area type shield them from domain wide flooding=20 information. Therefor those PEs will still remain selecting random paths = unless the proposal would also include static best path selection on=20 such PEs based on RT. We make the assumption that complete Internet routing information is available at every ASBR. If the local ASBR does not have reachibility to the relevant prefixes (or the ASBR itself is = not available), traffic should use the closest (in terms of IGP metric) egress. It would be interesting to see under what network conditions one could=20 assure that that every ASBR in the network contains complete Internet=20 routing. Then I would like to see prove on how using static RT mapping=20 to one's preference of some day assures reception and selection of paths = which could be categorized as "closest (in terms of IGP metric) egress". = Provided example of 3 ASBRs located on three continents of the world is=20 rather unreal considering today's network topologies where number of=20 ASBRs or IX interconnects very often reaches much larger numbers. Vinod# The draft also talks about scenarios of POPs with ASBRs having = only partial routes and not just complete routes. Once again this brings = us back to the original point elaborated above. An operator does not = need to build a model where each ASBR belongs to an individual RT. If my = objective is to use the local ASBR (having only 1000 prefixes for = instance) for known prefixes, and another ASBR(s) in a given region/POPs = (having full routes) - I would need to add in appropriate RT(s) for = signalling interest. Do take note, that the draft talks about the = possibility of indicating max-no-of-paths per RT - in the event of a PE = unable to take many a path advertised via ADD-PATH or even if the = constraints on path selection is more lenient. Flexibility is the key = here. * The title of the draft should reflect that the proposal does not=20 provide, a solution for "optimal" route reflection. The draft describes=20 a solution for "operator's statically configured ASBR path preferences". = Those two are quite dis-joined solutions. While perhaps under some=20 scenarios the end result may be the same at a given point of time there=20 is no guarantee that such result will stay as such during day to day=20 network operation. Vinod# Optimal route reflection is what the operator deems as optimal. = This draft provides the ability to instruct the RR to announce only a = set of paths that it considers optimal and choose between them. In other = words optimal is more relevant to the end user (PE) and not the RR. So = if the PE wants to use a path with the closest IGP metric, it indicates = the RR to only send paths that match a given RT.=20 * IDR WG draft does not require any manual static configuration of path=20 preferences - all required information is already present today on the=20 RR and can be readily used. * IDR WG draft can use add-paths to send more then best optimal path=20 from RR to the RR client - per clients preference Vinod# Same applies here. Key in this proposal (1) do not break the use = of BGP Peer groups (2) No churn on the RR re-calculating best path on = behalf of each PE in case of IGP fluctuations (3) More flexibility in = indicating the paths that are needed (4) max number of paths per RT can = be signalled (5) Each RR can be allocated an RT, and if a PE signals = only that RT in the RT constrain, then the RR calculated best path only = (default behaviour) is announced (6) Existing BGP machinery is re-used = for IPv4. * IDR WG draft dynamically recalculates optimal/closest IGP metric exist = point or points for each client and group of clients when ASBR=20 add/withdraw BGP routes or when IGP topology changes Vinod# IGP Churn impacting re-calculation?? * IDR WG draft provides ways to dynamically group clients based on their = common POP location / IGP area without any operator's configuration=20 burden on RR Vinod# Not just the ASBR with the closest IGP metric, but any affinity = to any combination of ASBR(s) can be chosen based on the policy of the = POP/individual PE can be deployed.=20 * IDR WG draft works equally well in normal IPv4/IPv6 networks as well=20 as with some form of tunneled networks without putting any requirement=20 on forwarding paradigm selection in the network Vinod# Not sure whether I follow this. The proposed draft focuses on = clearing the core or P routers (if you may) to steer clear of BGP = routing - for hot potato routing. But nothing stops an implementation = from using that. * It works in the same way for any AFI/SAFI and independently guarantees = calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6=20 paths as well as their distribution to the clients. Vinod# Per AF based policies can be used.=20 * IDR WG document provides ability for virtual RR placement in any IGP=20 network node location without any physical reconnection required. Such=20 provision is not addressed in the above document. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = idr-request@ietf.org Sent: 05 June 2011 20:00 To: idr@ietf.org Subject: Idr Digest, Vol 86, Issue 3 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/idr Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Idr mailing list submissions to idr@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/idr or, via email, send a message with subject or body 'help' to idr-request@ietf.org You can reach the person managing the list at idr-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Idr digest..." Today's Topics: 1. draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Robert Raszuk) 2. Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Jeff Tantsura) ---------------------------------------------------------------------- Message: 1 Date: Sun, 05 Jun 2011 00:51:57 +0200 From: Robert Raszuk To: "idr@ietf.org List" Subject: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Message-ID: <4DEAB70D.10403@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi, Attracted by the title I could not resit to read this draft. Here are=20 some of the comments and questions I have regarding the document. * Up front to make it very clear for all readers can authors explicitly=20 confirm that the applicability of this draft is only limited to networks = which use some form of tunneling (for example: MPLS) between each PE and = ASBRs ? * The idea of community based route selection on RRs is nothing new.=20 Using RT extended community as well as RT Constrain while does automates = the preference push from PE to RR to limit number of paths to be=20 received. However if also comes along with the following issues: - It does it in pure static way putting all burden of what can be=20 automated into the operator's NOC. Note that all information required=20 for optimal path selection is already present on RR without any need for = operational configuration burden today. - The networks topologies change dynamically which will not be=20 reflected in the static RT based preference. - Addition and deletion of new ASBR both planned and unplanned require = full reconfiguration of each PE to get to the same level of BGP path=20 redundancy reception. - Addition and deletion of new service POP both planned and unplanned=20 require full reconfiguration of each PE to get to the same level of BGP=20 path redundancy reception. - POPs which do not have local exit ASBRs and which do not leak next=20 hops from core to POP area in the IGP even if given opportunity to=20 receive _all_ external paths still have no visibility into the closet=20 exit ASBR in the domain as ABRs would typically depending on the IGP=20 selection and area type shield them from domain wide flooding=20 information. Therefor those PEs will still remain selecting random paths = unless the proposal would also include static best path selection on=20 such PEs based on RT. * The draft says: We make the assumption that complete Internet routing information is available at every ASBR. If the local ASBR does not have reachibility to the relevant prefixes (or the ASBR itself is = not available), traffic should use the closest (in terms of IGP metric) egress. It would be interesting to see under what network conditions one could=20 assure that that every ASBR in the network contains complete Internet=20 routing. Then I would like to see prove on how using static RT mapping=20 to one's preference of some day assures reception and selection of paths = which could be categorized as "closest (in terms of IGP metric) egress". = Provided example of 3 ASBRs located on three continents of the world is=20 rather unreal considering today's network topologies where number of=20 ASBRs or IX interconnects very often reaches much larger numbers. * The title of the draft should reflect that the proposal does not=20 provide, a solution for "optimal" route reflection. The draft describes=20 a solution for "operator's statically configured ASBR path preferences". = Those two are quite dis-joined solutions. While perhaps under some=20 scenarios the end result may be the same at a given point of time there=20 is no guarantee that such result will stay as such during day to day=20 network operation. * RT Constrain as proposed, implemented and deployed today has been=20 designed to express a VPN membership rules as an base object. While=20 there were some attempts to further divide this to be on per AFI/SAFI=20 basis RT Constrain authors came to the conclusion that those attempts=20 have no practical justification. In this proposal use of RT constrain=20 filtering would however result in the same exit ASBR preference to be=20 applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It is=20 already well known fact in operation today that optimal/closest exit=20 preferences for IPv4 unicast do not match in many networks the=20 optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs.=20 It would be interesting how authors of the proposed draft are going to=20 address this point going forward. *** Now let me take a moment to provide few points on number of advantages=20 of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 as = compared with the above document: * IDR WG draft does not require any manual static configuration of path=20 preferences - all required information is already present today on the=20 RR and can be readily used. * IDR WG draft can use add-paths to send more then best optimal path=20 from RR to the RR client - per clients preference * IDR WG draft dynamically recalculates optimal/closest IGP metric exist = point or points for each client and group of clients when ASBR=20 add/withdraw BGP routes or when IGP topology changes * IDR WG draft provides ways to dynamically group clients based on their = common POP location / IGP area without any operator's configuration=20 burden on RR * IDR WG draft works equally well in normal IPv4/IPv6 networks as well=20 as with some form of tunneled networks without putting any requirement=20 on forwarding paradigm selection in the network * It works in the same way for any AFI/SAFI and independently guarantees = calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6=20 paths as well as their distribution to the clients. * IDR WG document provides ability for virtual RR placement in any IGP=20 network node location without any physical reconnection required. Such=20 provision is not addressed in the above document. Best regards, R. ------------------------------ Message: 2 Date: Sat, 4 Jun 2011 22:05:08 -0400 From: Jeff Tantsura To: "raszuk@cisco.com" Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Message-ID: <94E61C27-F386-4EA7-B1CD-60A7619D3874@ericsson.com> Content-Type: text/plain; charset=3D"us-ascii" +1 Regards, Jeff On Jun 4, 2011, at 15:51, "Robert Raszuk" wrote: > Hi, >=20 > Attracted by the title I could not resit to read this draft. Here are=20 > some of the comments and questions I have regarding the document. >=20 > * Up front to make it very clear for all readers can authors = explicitly=20 > confirm that the applicability of this draft is only limited to = networks=20 > which use some form of tunneling (for example: MPLS) between each PE = and=20 > ASBRs ? >=20 > * The idea of community based route selection on RRs is nothing new.=20 > Using RT extended community as well as RT Constrain while does = automates=20 > the preference push from PE to RR to limit number of paths to be=20 > received. However if also comes along with the following issues: >=20 > - It does it in pure static way putting all burden of what can be=20 > automated into the operator's NOC. Note that all information required=20 > for optimal path selection is already present on RR without any need = for=20 > operational configuration burden today. >=20 > - The networks topologies change dynamically which will not be=20 > reflected in the static RT based preference. >=20 > - Addition and deletion of new ASBR both planned and unplanned = require=20 > full reconfiguration of each PE to get to the same level of BGP path=20 > redundancy reception. >=20 > - Addition and deletion of new service POP both planned and unplanned = > require full reconfiguration of each PE to get to the same level of = BGP=20 > path redundancy reception. >=20 > - POPs which do not have local exit ASBRs and which do not leak next=20 > hops from core to POP area in the IGP even if given opportunity to=20 > receive _all_ external paths still have no visibility into the closet=20 > exit ASBR in the domain as ABRs would typically depending on the IGP=20 > selection and area type shield them from domain wide flooding=20 > information. Therefor those PEs will still remain selecting random = paths=20 > unless the proposal would also include static best path selection on=20 > such PEs based on RT. >=20 > * The draft says: >=20 > We make the assumption that complete Internet routing > information is available at every ASBR. If the local ASBR does not > have reachibility to the relevant prefixes (or the ASBR itself is = not > available), traffic should use the closest (in terms of IGP metric) > egress. >=20 > It would be interesting to see under what network conditions one could = > assure that that every ASBR in the network contains complete Internet=20 > routing. Then I would like to see prove on how using static RT mapping = > to one's preference of some day assures reception and selection of = paths=20 > which could be categorized as "closest (in terms of IGP metric) = egress".=20 > Provided example of 3 ASBRs located on three continents of the world = is=20 > rather unreal considering today's network topologies where number of=20 > ASBRs or IX interconnects very often reaches much larger numbers. >=20 > * The title of the draft should reflect that the proposal does not=20 > provide, a solution for "optimal" route reflection. The draft = describes=20 > a solution for "operator's statically configured ASBR path = preferences".=20 > Those two are quite dis-joined solutions. While perhaps under some=20 > scenarios the end result may be the same at a given point of time = there=20 > is no guarantee that such result will stay as such during day to day=20 > network operation. >=20 > * RT Constrain as proposed, implemented and deployed today has been=20 > designed to express a VPN membership rules as an base object. While=20 > there were some attempts to further divide this to be on per AFI/SAFI=20 > basis RT Constrain authors came to the conclusion that those attempts=20 > have no practical justification. In this proposal use of RT constrain=20 > filtering would however result in the same exit ASBR preference to be=20 > applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It = is=20 > already well known fact in operation today that optimal/closest exit=20 > preferences for IPv4 unicast do not match in many networks the=20 > optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs. = > It would be interesting how authors of the proposed draft are going to = > address this point going forward. >=20 > *** >=20 > Now let me take a moment to provide few points on number of advantages = > of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 = as=20 > compared with the above document: >=20 > * IDR WG draft does not require any manual static configuration of = path=20 > preferences - all required information is already present today on the = > RR and can be readily used. >=20 > * IDR WG draft can use add-paths to send more then best optimal path=20 > from RR to the RR client - per clients preference >=20 > * IDR WG draft dynamically recalculates optimal/closest IGP metric = exist=20 > point or points for each client and group of clients when ASBR=20 > add/withdraw BGP routes or when IGP topology changes >=20 > * IDR WG draft provides ways to dynamically group clients based on = their=20 > common POP location / IGP area without any operator's configuration=20 > burden on RR >=20 > * IDR WG draft works equally well in normal IPv4/IPv6 networks as well = > as with some form of tunneled networks without putting any requirement = > on forwarding paradigm selection in the network >=20 > * It works in the same way for any AFI/SAFI and independently = guarantees=20 > calculation of optimal/closest exit points for IPv4, IPv4+label or = IPv6=20 > paths as well as their distribution to the clients. >=20 > * IDR WG document provides ability for virtual RR placement in any IGP = > network node location without any physical reconnection required. Such = > provision is not addressed in the above document. >=20 > Best regards, > R. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ------------------------------ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr End of Idr Digest, Vol 86, Issue 3 ********************************** From raszuk@cisco.com Sun Jun 5 13:58:11 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6C121F84E5 for ; Sun, 5 Jun 2011 13:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9 X-Spam-Level: X-Spam-Status: No, score=-9 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUK4NK3qaFWj for ; Sun, 5 Jun 2011 13:58:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2730621F84E4 for ; Sun, 5 Jun 2011 13:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=30005; q=dns/txt; s=iport; t=1307307489; x=1308517089; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=A+qJ36Wug7wfuZhDt8Oowu/RbPJZyoXgXh4EiAiotOc=; b=QCxgQC0JLtAAECd2HYCaC5ReoULs8GWBzoTFtzaxj6pt1rCHY8brZolX GZdWSsV/4gppZwrauJeBiBAhs3JyzBVGDk3xeFXBxpM4fdTaoXH7EMpR+ ou3gKR8HlhYFSFrzmAMU+rTskAVHP6ZD+Mp9sBdD8aKVM93oi+YMRAp1a 4=; X-IronPort-AV: E=Sophos;i="4.65,323,1304294400"; d="scan'208";a="370641780" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 05 Jun 2011 20:58:09 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p55Kw63B026461; Sun, 5 Jun 2011 20:58:07 GMT Message-ID: <4DEBEDEF.5000502@cisco.com> Date: Sun, 05 Jun 2011 22:58:23 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <5DD781A4BE13384A900438DF0608972C06996B0D@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996B0D@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 20:58:11 -0000 Hi Vinod, Let me reply to your post as it does indicate couple of issues with the understanding of draft-ietf-idr-bgp-optimal-route-reflection-00 further for simplicity referred to as IDR WG doc. > Vinod# You rightly said that RT constrain and Route Targets have been > used for a while now. The idea of this draft is to ensure that > existing BGP machinery successfully used in the context of other > address families, is used for IPv4. RT have been used for managing L3VPN imports and exports of routes since around 1999. While BGP can handle RT based filtering just fine there is significant management overhead to configure and maintain RT assignments. Only in lab, small networks or on ppt slides it looks neat. As someone who have been helping to deploy RFC2547 since day one I think I am entitled to say that use of RTs to manage VPNs is the biggest issue with that VPN technology. Personally if you would like to use extended communities for IPv4/IPv6 unicast/multicast filtering on RRs my recommendation would be to define a new type and to not mix it with VPN service RTs. > Policy control on the list of > paths needed is indicated by the PE through the use of RT constrain, > and only prefixes/paths that match the list of RTs specified are > announced by the RR, and the PEs do the best path calculation. In your reply you have not answered most of my points so let me reiterate ... * How PE is able to do best path calculation if it is in a POP or area without full visibility to the entire network of the provider ? Are you limiting applicability of your draft only to flat IGP networks running mpls ? * Imagine PE specify preference of receiving two paths one from ASBR1 and the other from ASBR2. Now for operational reasons ASBR1 goes down. Would you not have not to reconfigure such PE to ask for 2nd path from some other ASBR ? That is operationally real obstacle of your idea in any mid to large size of the network. * How your idea will work with PEs which yet do not support add-paths and yet do not support rt-constrain ? Let me here point out that all of those points just work fine in the IDR WG doc without any need to touch or load new software on the existing PEs. > The advantage here is > that the RR can be completely taken out of the picture as far as the > closest or optimal path calculation goes. For me this is a drawback not an advantage. RRs are intelligent control plane devices which can deliver real value to the routing in any network. On RRs you have already all routing information, memory and cpu to compute information which is needed. If you run out of current resources of one RR you add another RR to scale further. I am clearly against treating RR as dumb BGP repeaters - they can do much better. > Primarily this draft does not (1) break the use of BGP Peer groups > (2) cause network churn if there is an IGP change, since we are not > using an SPF instance per PE. IDR WG draft does not break use of peer groups either. Section 3.2 clearly describes a method to logically place RR in strategic network locations and distribute BGP paths from such location to the PEs. All PEs may still be in the same peer-group. If you have as described in your draft three exit strategic locations no matter where the actual RR physically sits you install 3 of them and tell each that one is in Japan, one in US and one in Europe and your PEs get 3 paths to choose from again without any need to burden yourself with management of new set of any RTs, reconfiguring PEs, requiring PEs to be upgraded to support new technologies and so on. Now since you keep bringing the topic of breaking peer groups I need to point few things. IDR WG doc does not break the concept of peer groups at all. Contrary to your misunderstanding it provides mechanism for automated peer grouping via very simple BGP OPEN message extension. Such peer grouping is constant and does not change with any IGP changes. So in any practical deployment of IDR WG doc described ORR you are at most talking about as many peer groups as you have POPs in your network. Excuse my optimism but if any RR can not deal today with 10s of peer groups I think it deserves an upgrade :) Last and not least concept of static peer groups is a history gone about 10 years ago in modern BGP implementations. Those use in shipping products dynamic update groups which adjust automatically to both peer's requirements, add-paths or policy advertisement rules without requiring and putting burden on operator to group the peers in a static and predefined way. As to your point of network churn IDR WG doc is very clear on two points. First not each network IGP change needs to resolve in any BGP action including even local re-evaluation of optimal best paths. There is clear definition of basic next hop metric change choice of threshold where if the change is below the line BGP does not need to react on it. Second please observe that IDR WG doc also enable to re advertise optimal path or paths only to those POPs where the IGP change would affect them. That alone contrary to today's case has clear benefit of BGP wave effect reduction ... something which I hope everyone would see as a positive outcome. > Vinod# Like I mentioned, planning for resiliency and allocation of > RTs are flexible. It is not mandatory to have a single ASBR be > allotted a single RT, multiple ASBRs may share the same RT. It is not the point that you can not ask for list of N RTs. Sure you can. The point is that those RTs PE ask for are only as good as those RTs will be attached to a given route by the ASBRs in the first place. Let me illustrate more precisely the issue ... Imagine you have 10 ASBRs and PEs have constructed the list of set of two RTs RT1 and RT2 to get two paths from RRs corresponding to their preference. Now it so happens that while RR has still 8 paths to a given destination two of them are withdrawn due to a problem with some upstream transit ISP two ASes up the tree. It also so happens that those two paths were those which set of PEs signaled to get. Conclusion: Your network has still 8 valid paths to reach set of destinations however large number of PEs report OUTAGE !!! Their preferred paths are no longer available .. maybe for few seconds .. maybe for few minutes ... maybe for an hour. Till NOC eng in the network which supports your draft logs to the PEs and reconfigure the list of RTs they were considering "optimal" perhaps hundreds of such operators customers are really upset as they lost their favorite show or cricket game view not to even mention other much more critical uses of networks today which go way beyond entertainment. Your draft breaks by design a basic network architecture rule .. if you have reachability to a destination your policy whatever it is should not result in your customer's to loose reachability to said destination. . . . I could continue to address your other points, but I think we are done right here and no further discussion is needed, before you really prove that your idea does not fall into the above showstopper. Best regards, R. PS. The use of the exact same name of totally different and quite broken idea as compared with already existing a WG document I think is a precedence in the IETF. By any measures of probability this is not an accident :) I find it odd to say at least and while I hope the goal of the drafts is not cause distraction in the working group I would like to see WG chairs as well as AD's (Bcc-ed) official IETF opinion on it. > Robert, > > The objective of the draft is to provide closest exit routing based > on the operators preference. Let me answer each of the comments > inline: > >> It does it in pure static way putting all burden of what can be > automated into the operator's NOC. Note that all information > required for optimal path selection is already present on RR without > any need for operational configuration burden today. > > Vinod# You rightly said that RT constrain and Route Targets have been > used for a while now. The idea of this draft is to ensure that > existing BGP machinery successfully used in the context of other > address families, is used for IPv4. Policy control on the list of > paths needed is indicated by the PE through the use of RT constrain, > and only prefixes/paths that match the list of RTs specified are > announced by the RR, and the PEs do the best path calculation. It is > arguable that policy control via RT constrain adds operational burden > - since the use of RT and RT constrain have been used on other > address families for ages as you mentioned. The advantage here is > that the RR can be completely taken out of the picture as far as the > closest or optimal path calculation goes. > > The networks topologies change dynamically which will not be > reflected in the static RT based preference. > > Vinod# Let me put it this way, an operator may prefer a list of RTs > and not just a single RT - if we assume a single RT maps to a single > ASBR, to build resiliency. The objective is clear - provide the > operator with an approach to selectively choose the best path, and > also indicate a list of affinities (list of RTs) that a PE is > interested in. It is also possible to extend the scheme where all > ASBRs within a region = a single RT. Therefore there is flexibility. > Primarily this draft does not (1) break the use of BGP Peer groups > (2) cause network churn if there is an IGP change, since we are not > using an SPF instance per PE. > > - Addition and deletion of new ASBR both planned and unplanned > require full reconfiguration of each PE to get to the same level of > BGP path redundancy reception. > > Vinod# Like I mentioned, planning for resiliency and allocation of > RTs are flexible. It is not mandatory to have a single ASBR be > allotted a single RT, multiple ASBRs may share the same RT. > >> POPs which do not have local exit ASBRs and which do not leak next > hops from core to POP area in the IGP even if given opportunity to > receive _all_ external paths still have no visibility into the > closet exit ASBR in the domain as ABRs would typically depending on > the IGP selection and area type shield them from domain wide > flooding information. Therefor those PEs will still remain selecting > random paths unless the proposal would also include static best path > selection on such PEs based on RT. > > > We make the assumption that complete Internet routing information is > available at every ASBR. If the local ASBR does not have reachibility > to the relevant prefixes (or the ASBR itself is not available), > traffic should use the closest (in terms of IGP metric) egress. > > It would be interesting to see under what network conditions one > could assure that that every ASBR in the network contains complete > Internet routing. Then I would like to see prove on how using static > RT mapping to one's preference of some day assures reception and > selection of paths which could be categorized as "closest (in terms > of IGP metric) egress". Provided example of 3 ASBRs located on three > continents of the world is rather unreal considering today's network > topologies where number of ASBRs or IX interconnects very often > reaches much larger numbers. > > Vinod# The draft also talks about scenarios of POPs with ASBRs having > only partial routes and not just complete routes. Once again this > brings us back to the original point elaborated above. An operator > does not need to build a model where each ASBR belongs to an > individual RT. If my objective is to use the local ASBR (having only > 1000 prefixes for instance) for known prefixes, and another ASBR(s) > in a given region/POPs (having full routes) - I would need to add in > appropriate RT(s) for signalling interest. Do take note, that the > draft talks about the possibility of indicating max-no-of-paths per > RT - in the event of a PE unable to take many a path advertised via > ADD-PATH or even if the constraints on path selection is more > lenient. Flexibility is the key here. > > * The title of the draft should reflect that the proposal does not > provide, a solution for "optimal" route reflection. The draft > describes a solution for "operator's statically configured ASBR path > preferences". Those two are quite dis-joined solutions. While perhaps > under some scenarios the end result may be the same at a given point > of time there is no guarantee that such result will stay as such > during day to day network operation. > > > Vinod# Optimal route reflection is what the operator deems as > optimal. This draft provides the ability to instruct the RR to > announce only a set of paths that it considers optimal and choose > between them. In other words optimal is more relevant to the end user > (PE) and not the RR. So if the PE wants to use a path with the > closest IGP metric, it indicates the RR to only send paths that match > a given RT. > > * IDR WG draft does not require any manual static configuration of > path preferences - all required information is already present today > on the RR and can be readily used. > > * IDR WG draft can use add-paths to send more then best optimal path > from RR to the RR client - per clients preference > > Vinod# Same applies here. Key in this proposal (1) do not break the > use of BGP Peer groups (2) No churn on the RR re-calculating best > path on behalf of each PE in case of IGP fluctuations (3) More > flexibility in indicating the paths that are needed (4) max number of > paths per RT can be signalled (5) Each RR can be allocated an RT, and > if a PE signals only that RT in the RT constrain, then the RR > calculated best path only (default behaviour) is announced (6) > Existing BGP machinery is re-used for IPv4. > > * IDR WG draft dynamically recalculates optimal/closest IGP metric > exist point or points for each client and group of clients when ASBR > add/withdraw BGP routes or when IGP topology changes > > Vinod# IGP Churn impacting re-calculation?? > > * IDR WG draft provides ways to dynamically group clients based on > their common POP location / IGP area without any operator's > configuration burden on RR > > Vinod# Not just the ASBR with the closest IGP metric, but any > affinity to any combination of ASBR(s) can be chosen based on the > policy of the POP/individual PE can be deployed. > > * IDR WG draft works equally well in normal IPv4/IPv6 networks as > well as with some form of tunneled networks without putting any > requirement on forwarding paradigm selection in the network > > Vinod# Not sure whether I follow this. The proposed draft focuses on > clearing the core or P routers (if you may) to steer clear of BGP > routing - for hot potato routing. But nothing stops an implementation > from using that. > > * It works in the same way for any AFI/SAFI and independently > guarantees calculation of optimal/closest exit points for IPv4, > IPv4+label or IPv6 paths as well as their distribution to the > clients. > > Vinod# Per AF based policies can be used. > > * IDR WG document provides ability for virtual RR placement in any > IGP network node location without any physical reconnection required. > Such provision is not addressed in the above document. > > > Regards > > Vinod Joseph Professional Services - Service Provider Europe Juniper > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net > > > > -----Original Message----- From: idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] On Behalf Of idr-request@ietf.org Sent: > 05 June 2011 20:00 To: idr@ietf.org Subject: Idr Digest, Vol 86, > Issue 3 > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/idr > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send Idr mailing list submissions to idr@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/idr or, via email, send a > message with subject or body 'help' to idr-request@ietf.org > > You can reach the person managing the list at idr-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Idr digest..." > > > Today's Topics: > > 1. draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Robert > Raszuk) 2. Re: > draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Jeff > Tantsura) > > > ---------------------------------------------------------------------- > > Message: 1 Date: Sun, 05 Jun 2011 00:51:57 +0200 From: Robert > Raszuk To: "idr@ietf.org List" > Subject: [Idr] > draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt > Message-ID:<4DEAB70D.10403@cisco.com> Content-Type: text/plain; > charset=ISO-8859-1; format=flowed > > Hi, > > Attracted by the title I could not resit to read this draft. Here > are some of the comments and questions I have regarding the > document. > > * Up front to make it very clear for all readers can authors > explicitly confirm that the applicability of this draft is only > limited to networks which use some form of tunneling (for example: > MPLS) between each PE and ASBRs ? > > * The idea of community based route selection on RRs is nothing new. > Using RT extended community as well as RT Constrain while does > automates the preference push from PE to RR to limit number of paths > to be received. However if also comes along with the following > issues: > > - It does it in pure static way putting all burden of what can be > automated into the operator's NOC. Note that all information > required for optimal path selection is already present on RR without > any need for operational configuration burden today. > > - The networks topologies change dynamically which will not be > reflected in the static RT based preference. > > - Addition and deletion of new ASBR both planned and unplanned > require full reconfiguration of each PE to get to the same level of > BGP path redundancy reception. > > - Addition and deletion of new service POP both planned and > unplanned require full reconfiguration of each PE to get to the same > level of BGP path redundancy reception. > > - POPs which do not have local exit ASBRs and which do not leak next > hops from core to POP area in the IGP even if given opportunity to > receive _all_ external paths still have no visibility into the > closet exit ASBR in the domain as ABRs would typically depending on > the IGP selection and area type shield them from domain wide > flooding information. Therefor those PEs will still remain selecting > random paths unless the proposal would also include static best path > selection on such PEs based on RT. > > * The draft says: > > We make the assumption that complete Internet routing information is > available at every ASBR. If the local ASBR does not have reachibility > to the relevant prefixes (or the ASBR itself is not available), > traffic should use the closest (in terms of IGP metric) egress. > > It would be interesting to see under what network conditions one > could assure that that every ASBR in the network contains complete > Internet routing. Then I would like to see prove on how using static > RT mapping to one's preference of some day assures reception and > selection of paths which could be categorized as "closest (in terms > of IGP metric) egress". Provided example of 3 ASBRs located on three > continents of the world is rather unreal considering today's network > topologies where number of ASBRs or IX interconnects very often > reaches much larger numbers. > > * The title of the draft should reflect that the proposal does not > provide, a solution for "optimal" route reflection. The draft > describes a solution for "operator's statically configured ASBR path > preferences". Those two are quite dis-joined solutions. While perhaps > under some scenarios the end result may be the same at a given point > of time there is no guarantee that such result will stay as such > during day to day network operation. > > * RT Constrain as proposed, implemented and deployed today has been > designed to express a VPN membership rules as an base object. While > there were some attempts to further divide this to be on per > AFI/SAFI basis RT Constrain authors came to the conclusion that those > attempts have no practical justification. In this proposal use of RT > constrain filtering would however result in the same exit ASBR > preference to be applied for IPv4 as to the IPv6 with or without > labels AFI/SAFIs. It is already well known fact in operation today > that optimal/closest exit preferences for IPv4 unicast do not match > in many networks the optimal/closest exit preferences for IPv6 or for > IPv4+label AFI/SAFIs. It would be interesting how authors of the > proposed draft are going to address this point going forward. > > *** > > Now let me take a moment to provide few points on number of > advantages of the IDR WG document > draft-ietf-idr-bgp-optimal-route-reflection-00 as compared with the > above document: > > * IDR WG draft does not require any manual static configuration of > path preferences - all required information is already present today > on the RR and can be readily used. > > * IDR WG draft can use add-paths to send more then best optimal path > from RR to the RR client - per clients preference > > * IDR WG draft dynamically recalculates optimal/closest IGP metric > exist point or points for each client and group of clients when ASBR > add/withdraw BGP routes or when IGP topology changes > > * IDR WG draft provides ways to dynamically group clients based on > their common POP location / IGP area without any operator's > configuration burden on RR > > * IDR WG draft works equally well in normal IPv4/IPv6 networks as > well as with some form of tunneled networks without putting any > requirement on forwarding paradigm selection in the network > > * It works in the same way for any AFI/SAFI and independently > guarantees calculation of optimal/closest exit points for IPv4, > IPv4+label or IPv6 paths as well as their distribution to the > clients. > > * IDR WG document provides ability for virtual RR placement in any > IGP network node location without any physical reconnection required. > Such provision is not addressed in the above document. > > Best regards, R. > > > ------------------------------ > > Message: 2 Date: Sat, 4 Jun 2011 22:05:08 -0400 From: Jeff > Tantsura To: > "raszuk@cisco.com" Cc: "idr@ietf.org > List" Subject: Re: [Idr] > draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt > Message-ID:<94E61C27-F386-4EA7-B1CD-60A7619D3874@ericsson.com> > Content-Type: text/plain; charset="us-ascii" > > +1 > > Regards, Jeff > > On Jun 4, 2011, at 15:51, "Robert Raszuk" wrote: > >> Hi, >> >> Attracted by the title I could not resit to read this draft. Here >> are some of the comments and questions I have regarding the >> document. >> >> * Up front to make it very clear for all readers can authors >> explicitly confirm that the applicability of this draft is only >> limited to networks which use some form of tunneling (for example: >> MPLS) between each PE and ASBRs ? >> >> * The idea of community based route selection on RRs is nothing >> new. Using RT extended community as well as RT Constrain while does >> automates the preference push from PE to RR to limit number of >> paths to be received. However if also comes along with the >> following issues: >> >> - It does it in pure static way putting all burden of what can be >> automated into the operator's NOC. Note that all information >> required for optimal path selection is already present on RR >> without any need for operational configuration burden today. >> >> - The networks topologies change dynamically which will not be >> reflected in the static RT based preference. >> >> - Addition and deletion of new ASBR both planned and unplanned >> require full reconfiguration of each PE to get to the same level of >> BGP path redundancy reception. >> >> - Addition and deletion of new service POP both planned and >> unplanned require full reconfiguration of each PE to get to the >> same level of BGP path redundancy reception. >> >> - POPs which do not have local exit ASBRs and which do not leak >> next hops from core to POP area in the IGP even if given >> opportunity to receive _all_ external paths still have no >> visibility into the closet exit ASBR in the domain as ABRs would >> typically depending on the IGP selection and area type shield them >> from domain wide flooding information. Therefor those PEs will >> still remain selecting random paths unless the proposal would also >> include static best path selection on such PEs based on RT. >> >> * The draft says: >> >> We make the assumption that complete Internet routing information >> is available at every ASBR. If the local ASBR does not have >> reachibility to the relevant prefixes (or the ASBR itself is not >> available), traffic should use the closest (in terms of IGP >> metric) egress. >> >> It would be interesting to see under what network conditions one >> could assure that that every ASBR in the network contains complete >> Internet routing. Then I would like to see prove on how using >> static RT mapping to one's preference of some day assures reception >> and selection of paths which could be categorized as "closest (in >> terms of IGP metric) egress". Provided example of 3 ASBRs located >> on three continents of the world is rather unreal considering >> today's network topologies where number of ASBRs or IX >> interconnects very often reaches much larger numbers. >> >> * The title of the draft should reflect that the proposal does not >> provide, a solution for "optimal" route reflection. The draft >> describes a solution for "operator's statically configured ASBR >> path preferences". Those two are quite dis-joined solutions. While >> perhaps under some scenarios the end result may be the same at a >> given point of time there is no guarantee that such result will >> stay as such during day to day network operation. >> >> * RT Constrain as proposed, implemented and deployed today has >> been designed to express a VPN membership rules as an base object. >> While there were some attempts to further divide this to be on per >> AFI/SAFI basis RT Constrain authors came to the conclusion that >> those attempts have no practical justification. In this proposal >> use of RT constrain filtering would however result in the same exit >> ASBR preference to be applied for IPv4 as to the IPv6 with or >> without labels AFI/SAFIs. It is already well known fact in >> operation today that optimal/closest exit preferences for IPv4 >> unicast do not match in many networks the optimal/closest exit >> preferences for IPv6 or for IPv4+label AFI/SAFIs. It would be >> interesting how authors of the proposed draft are going to address >> this point going forward. >> >> *** >> >> Now let me take a moment to provide few points on number of >> advantages of the IDR WG document >> draft-ietf-idr-bgp-optimal-route-reflection-00 as compared with the >> above document: >> >> * IDR WG draft does not require any manual static configuration of >> path preferences - all required information is already present >> today on the RR and can be readily used. >> >> * IDR WG draft can use add-paths to send more then best optimal >> path from RR to the RR client - per clients preference >> >> * IDR WG draft dynamically recalculates optimal/closest IGP metric >> exist point or points for each client and group of clients when >> ASBR add/withdraw BGP routes or when IGP topology changes >> >> * IDR WG draft provides ways to dynamically group clients based on >> their common POP location / IGP area without any operator's >> configuration burden on RR >> >> * IDR WG draft works equally well in normal IPv4/IPv6 networks as >> well as with some form of tunneled networks without putting any >> requirement on forwarding paradigm selection in the network >> >> * It works in the same way for any AFI/SAFI and independently >> guarantees calculation of optimal/closest exit points for IPv4, >> IPv4+label or IPv6 paths as well as their distribution to the >> clients. >> >> * IDR WG document provides ability for virtual RR placement in any >> IGP network node location without any physical reconnection >> required. Such provision is not addressed in the above document. >> >> Best regards, R. _______________________________________________ >> Idr mailing list Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > > ------------------------------ > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > > End of Idr Digest, Vol 86, Issue 3 > ********************************** > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > From raszuk@cisco.com Sun Jun 5 14:24:25 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4679821F84F9 for ; Sun, 5 Jun 2011 14:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rs+41iAqTCm for ; Sun, 5 Jun 2011 14:24:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id A1AC421F84F1 for ; Sun, 5 Jun 2011 14:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1168; q=dns/txt; s=iport; t=1307309064; x=1308518664; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=xb8+Bi5b/Cevybpb/06oY4rO2pvattIUUVGWXxpOve8=; b=CXZ3PpiYW4QtjI8zpewVNZ3f3oUlhuOWqTBkS224JsKVCAKjwVvXgssQ SDDNjuaIEWxyr0iq/YcSaJ4V9OU4ZvkU0iTD4O7xM5ER4db3lpvAMazqE V9qY8+73hyZqFsjlShxrR7v9+Cj0yxb+6dZIwy5s9/pbv/KCmxYSsv6Xj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIHABzz602rRDoH/2dsb2JhbABTmBeOH3epVIJ8DwGZVYYhBJB5hEiKdA X-IronPort-AV: E=Sophos;i="4.65,323,1304294400"; d="scan'208";a="330580140" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 05 Jun 2011 21:24:22 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p55LOL7X032574 for ; Sun, 5 Jun 2011 21:24:22 GMT Message-ID: <4DEBF416.5060907@cisco.com> Date: Sun, 05 Jun 2011 23:24:38 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <5DD781A4BE13384A900438DF0608972C06996B0D@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996B0D@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 21:24:25 -0000 Vinod, Let me also describe how all goals of your draft are met by IDR WG doc as well as by associated with it Next-Hop SAFI draft (draft-varlashkin-bgp-nh-cost-01) without any need for using SPF on the RRs. Imagine you have number of PEs which per operator's logic know their exit preference. Using new NH-SAFI they can idicate to RR their own local metric to each of available next hop. If one or N of those paths with previously advertised next hops goes away RR will immediately replace it with new set of available paths. This is simplest form of local operator decision on what is the order of paths in the network yet number of paths received by PE is decoupled from the preference (unlike in your draft). It is also robust as at any point it will not result in the customer's outage. Here I would like to thank you for highlighting within our discussion that PE driven provider's optimal path selection is requested by some operators. This will clearly help to progress draft-varlashkin-bgp-nh-cost-01 and it's implementations further and it offers a very good tool to accomplish such requirement. Best regards, R. From vjoseph@juniper.net Mon Jun 6 07:10:51 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAB611E8135 for ; Mon, 6 Jun 2011 07:10:51 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ojdbpXXh1p2 for ; Mon, 6 Jun 2011 07:10:49 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2720A11E8155 for ; Mon, 6 Jun 2011 07:10:47 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTezf4gk/Zlx/BH2a+zQ86BONUweofOKc@postini.com; Mon, 06 Jun 2011 07:10:49 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Mon, 6 Jun 2011 07:09:22 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 15:09:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2011 15:09:16 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996C95@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Thread-Index: AcwjsuDJanNCP/FhSd2Ne8+PbBAdcgAAUgYQACcjR0A= References: <90D18849576F6C41A6178B62DECAFD0F1BBDD242@emailemea4.jnpr.net> From: Vinod Joseph To: X-OriginalArrivalTime: 06 Jun 2011 14:09:21.0494 (UTC) FILETIME=[55109F60:01CC2453] Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:10:51 -0000 Robert, More inline -=20 Up front to make it very clear for all readers can authors explicitly=20 confirm that the applicability of this draft is only limited to=20 networks which use some form of tunneling (for example: MPLS) between=20 each PE and ASBRs ? Vinod# Yes POPs which do not have local exit ASBRs and which do not leak next=20 hops from core to POP area in the IGP even if given opportunity to=20 receive _all_ external paths still have no visibility into the closet=20 exit ASBR in the domain as ABRs would typically depending on the IGP=20 selection and area type shield them from domain wide flooding=20 information. Therefor those PEs will still remain selecting random=20 paths unless the proposal would also include static best path=20 selection on such PEs based on RT. Vinod# Can you explain this, not sure whether I follow your question? RT Constrain as proposed, implemented and deployed today has been=20 designed to express a VPN membership rules as an base object. While=20 there were some attempts to further divide this to be on per AFI/SAFI=20 basis RT Constrain authors came to the conclusion that those attempts=20 have no practical justification. In this proposal use of RT constrain=20 filtering would however result in the same exit ASBR preference to be=20 applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. Vinod# Why is that the case? RTs would control the set of paths that a = PE would receive. However the choice of which of these to pick could be = different for IPv4 and IPv6. However if the desire is to have different sets for IPv4 and different = sets for IPv6 then one way to solve this is to have different RTs for = IPv4 and IPv6. With this model if a PE has both IPv4 and IPv6 routes, it = would use different RTs for v4 and v6. In the case of VPNs, some vendors said that they wanted to reuse the = same RT for IPv4 and IPv6 VPNs and yet not send IPv4 routes to an IPv6 = only PE, for example. Hence there was discussion on AFI/SAFI granularity = for RT constrain. For the purposes of this draft the solution is = probably much simpler. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Vinod Joseph=20 Sent: 05 June 2011 20:58 To: idr@ietf.org Subject: RE: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Robert, The objective of the draft is to provide closest exit routing based on = the operators preference. Let me answer each of the comments inline: > It does it in pure static way putting all burden of what can be=20 automated into the operator's NOC. Note that all information required=20 for optimal path selection is already present on RR without any need for = operational configuration burden today. Vinod# You rightly said that RT constrain and Route Targets have been = used for a while now. The idea of this draft is to ensure that existing = BGP machinery successfully used in the context of other address = families, is used for IPv4. Policy control on the list of paths needed = is indicated by the PE through the use of RT constrain, and only = prefixes/paths that match the list of RTs specified are announced by the = RR, and the PEs do the best path calculation. It is arguable that policy = control via RT constrain adds operational burden - since the use of RT = and RT constrain have been used on other address families for ages as = you mentioned. The advantage here is that the RR can be completely taken = out of the picture as far as the closest or optimal path calculation = goes. The networks topologies change dynamically which will not be=20 reflected in the static RT based preference. Vinod# Let me put it this way, an operator may prefer a list of RTs and = not just a single RT - if we assume a single RT maps to a single ASBR, = to build resiliency. The objective is clear - provide the operator with = an approach to selectively choose the best path, and also indicate a = list of affinities (list of RTs) that a PE is interested in. It is also = possible to extend the scheme where all ASBRs within a region =3D a = single RT. Therefore there is flexibility. Primarily this draft does not = (1) break the use of BGP Peer groups (2) cause network churn if there is = an IGP change, since we are not using an SPF instance per PE.=20 - Addition and deletion of new ASBR both planned and unplanned require=20 full reconfiguration of each PE to get to the same level of BGP path=20 redundancy reception. Vinod# Like I mentioned, planning for resiliency and allocation of RTs = are flexible. It is not mandatory to have a single ASBR be allotted a = single RT, multiple ASBRs may share the same RT. > POPs which do not have local exit ASBRs and which do not leak next=20 hops from core to POP area in the IGP even if given opportunity to=20 receive _all_ external paths still have no visibility into the closet=20 exit ASBR in the domain as ABRs would typically depending on the IGP=20 selection and area type shield them from domain wide flooding=20 information. Therefor those PEs will still remain selecting random paths = unless the proposal would also include static best path selection on=20 such PEs based on RT. We make the assumption that complete Internet routing information is available at every ASBR. If the local ASBR does not have reachibility to the relevant prefixes (or the ASBR itself is = not available), traffic should use the closest (in terms of IGP metric) egress. It would be interesting to see under what network conditions one could=20 assure that that every ASBR in the network contains complete Internet=20 routing. Then I would like to see prove on how using static RT mapping=20 to one's preference of some day assures reception and selection of paths = which could be categorized as "closest (in terms of IGP metric) egress". = Provided example of 3 ASBRs located on three continents of the world is=20 rather unreal considering today's network topologies where number of=20 ASBRs or IX interconnects very often reaches much larger numbers. Vinod# The draft also talks about scenarios of POPs with ASBRs having = only partial routes and not just complete routes. Once again this brings = us back to the original point elaborated above. An operator does not = need to build a model where each ASBR belongs to an individual RT. If my = objective is to use the local ASBR (having only 1000 prefixes for = instance) for known prefixes, and another ASBR(s) in a given region/POPs = (having full routes) - I would need to add in appropriate RT(s) for = signalling interest. Do take note, that the draft talks about the = possibility of indicating max-no-of-paths per RT - in the event of a PE = unable to take many a path advertised via ADD-PATH or even if the = constraints on path selection is more lenient. Flexibility is the key = here. * The title of the draft should reflect that the proposal does not=20 provide, a solution for "optimal" route reflection. The draft describes=20 a solution for "operator's statically configured ASBR path preferences". = Those two are quite dis-joined solutions. While perhaps under some=20 scenarios the end result may be the same at a given point of time there=20 is no guarantee that such result will stay as such during day to day=20 network operation. Vinod# Optimal route reflection is what the operator deems as optimal. = This draft provides the ability to instruct the RR to announce only a = set of paths that it considers optimal and choose between them. In other = words optimal is more relevant to the end user (PE) and not the RR. So = if the PE wants to use a path with the closest IGP metric, it indicates = the RR to only send paths that match a given RT.=20 * IDR WG draft does not require any manual static configuration of path=20 preferences - all required information is already present today on the=20 RR and can be readily used. * IDR WG draft can use add-paths to send more then best optimal path=20 from RR to the RR client - per clients preference Vinod# Same applies here. Key in this proposal (1) do not break the use = of BGP Peer groups (2) No churn on the RR re-calculating best path on = behalf of each PE in case of IGP fluctuations (3) More flexibility in = indicating the paths that are needed (4) max number of paths per RT can = be signalled (5) Each RR can be allocated an RT, and if a PE signals = only that RT in the RT constrain, then the RR calculated best path only = (default behaviour) is announced (6) Existing BGP machinery is re-used = for IPv4. * IDR WG draft dynamically recalculates optimal/closest IGP metric exist = point or points for each client and group of clients when ASBR=20 add/withdraw BGP routes or when IGP topology changes Vinod# IGP Churn impacting re-calculation?? * IDR WG draft provides ways to dynamically group clients based on their = common POP location / IGP area without any operator's configuration=20 burden on RR Vinod# Not just the ASBR with the closest IGP metric, but any affinity = to any combination of ASBR(s) can be chosen based on the policy of the = POP/individual PE can be deployed.=20 * IDR WG draft works equally well in normal IPv4/IPv6 networks as well=20 as with some form of tunneled networks without putting any requirement=20 on forwarding paradigm selection in the network Vinod# Not sure whether I follow this. The proposed draft focuses on = clearing the core or P routers (if you may) to steer clear of BGP = routing - for hot potato routing. But nothing stops an implementation = from using that. * It works in the same way for any AFI/SAFI and independently guarantees = calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6=20 paths as well as their distribution to the clients. Vinod# Per AF based policies can be used.=20 * IDR WG document provides ability for virtual RR placement in any IGP=20 network node location without any physical reconnection required. Such=20 provision is not addressed in the above document. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = idr-request@ietf.org Sent: 05 June 2011 20:00 To: idr@ietf.org Subject: Idr Digest, Vol 86, Issue 3 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/idr Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Idr mailing list submissions to idr@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/idr or, via email, send a message with subject or body 'help' to idr-request@ietf.org You can reach the person managing the list at idr-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Idr digest..." Today's Topics: 1. draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Robert Raszuk) 2. Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Jeff Tantsura) ---------------------------------------------------------------------- Message: 1 Date: Sun, 05 Jun 2011 00:51:57 +0200 From: Robert Raszuk To: "idr@ietf.org List" Subject: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Message-ID: <4DEAB70D.10403@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi, Attracted by the title I could not resit to read this draft. Here are=20 some of the comments and questions I have regarding the document. * Up front to make it very clear for all readers can authors explicitly=20 confirm that the applicability of this draft is only limited to networks = which use some form of tunneling (for example: MPLS) between each PE and = ASBRs ? * The idea of community based route selection on RRs is nothing new.=20 Using RT extended community as well as RT Constrain while does automates = the preference push from PE to RR to limit number of paths to be=20 received. However if also comes along with the following issues: - It does it in pure static way putting all burden of what can be=20 automated into the operator's NOC. Note that all information required=20 for optimal path selection is already present on RR without any need for = operational configuration burden today. - The networks topologies change dynamically which will not be=20 reflected in the static RT based preference. - Addition and deletion of new ASBR both planned and unplanned require = full reconfiguration of each PE to get to the same level of BGP path=20 redundancy reception. - Addition and deletion of new service POP both planned and unplanned=20 require full reconfiguration of each PE to get to the same level of BGP=20 path redundancy reception. - POPs which do not have local exit ASBRs and which do not leak next=20 hops from core to POP area in the IGP even if given opportunity to=20 receive _all_ external paths still have no visibility into the closet=20 exit ASBR in the domain as ABRs would typically depending on the IGP=20 selection and area type shield them from domain wide flooding=20 information. Therefor those PEs will still remain selecting random paths = unless the proposal would also include static best path selection on=20 such PEs based on RT. * The draft says: We make the assumption that complete Internet routing information is available at every ASBR. If the local ASBR does not have reachibility to the relevant prefixes (or the ASBR itself is = not available), traffic should use the closest (in terms of IGP metric) egress. It would be interesting to see under what network conditions one could=20 assure that that every ASBR in the network contains complete Internet=20 routing. Then I would like to see prove on how using static RT mapping=20 to one's preference of some day assures reception and selection of paths = which could be categorized as "closest (in terms of IGP metric) egress". = Provided example of 3 ASBRs located on three continents of the world is=20 rather unreal considering today's network topologies where number of=20 ASBRs or IX interconnects very often reaches much larger numbers. * The title of the draft should reflect that the proposal does not=20 provide, a solution for "optimal" route reflection. The draft describes=20 a solution for "operator's statically configured ASBR path preferences". = Those two are quite dis-joined solutions. While perhaps under some=20 scenarios the end result may be the same at a given point of time there=20 is no guarantee that such result will stay as such during day to day=20 network operation. * RT Constrain as proposed, implemented and deployed today has been=20 designed to express a VPN membership rules as an base object. While=20 there were some attempts to further divide this to be on per AFI/SAFI=20 basis RT Constrain authors came to the conclusion that those attempts=20 have no practical justification. In this proposal use of RT constrain=20 filtering would however result in the same exit ASBR preference to be=20 applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It is=20 already well known fact in operation today that optimal/closest exit=20 preferences for IPv4 unicast do not match in many networks the=20 optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs.=20 It would be interesting how authors of the proposed draft are going to=20 address this point going forward. *** Now let me take a moment to provide few points on number of advantages=20 of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 as = compared with the above document: * IDR WG draft does not require any manual static configuration of path=20 preferences - all required information is already present today on the=20 RR and can be readily used. * IDR WG draft can use add-paths to send more then best optimal path=20 from RR to the RR client - per clients preference * IDR WG draft dynamically recalculates optimal/closest IGP metric exist = point or points for each client and group of clients when ASBR=20 add/withdraw BGP routes or when IGP topology changes * IDR WG draft provides ways to dynamically group clients based on their = common POP location / IGP area without any operator's configuration=20 burden on RR * IDR WG draft works equally well in normal IPv4/IPv6 networks as well=20 as with some form of tunneled networks without putting any requirement=20 on forwarding paradigm selection in the network * It works in the same way for any AFI/SAFI and independently guarantees = calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6=20 paths as well as their distribution to the clients. * IDR WG document provides ability for virtual RR placement in any IGP=20 network node location without any physical reconnection required. Such=20 provision is not addressed in the above document. Best regards, R. ------------------------------ Message: 2 Date: Sat, 4 Jun 2011 22:05:08 -0400 From: Jeff Tantsura To: "raszuk@cisco.com" Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Message-ID: <94E61C27-F386-4EA7-B1CD-60A7619D3874@ericsson.com> Content-Type: text/plain; charset=3D"us-ascii" +1 Regards, Jeff On Jun 4, 2011, at 15:51, "Robert Raszuk" wrote: > Hi, >=20 > Attracted by the title I could not resit to read this draft. Here are=20 > some of the comments and questions I have regarding the document. >=20 > * Up front to make it very clear for all readers can authors = explicitly=20 > confirm that the applicability of this draft is only limited to = networks=20 > which use some form of tunneling (for example: MPLS) between each PE = and=20 > ASBRs ? >=20 > * The idea of community based route selection on RRs is nothing new.=20 > Using RT extended community as well as RT Constrain while does = automates=20 > the preference push from PE to RR to limit number of paths to be=20 > received. However if also comes along with the following issues: >=20 > - It does it in pure static way putting all burden of what can be=20 > automated into the operator's NOC. Note that all information required=20 > for optimal path selection is already present on RR without any need = for=20 > operational configuration burden today. >=20 > - The networks topologies change dynamically which will not be=20 > reflected in the static RT based preference. >=20 > - Addition and deletion of new ASBR both planned and unplanned = require=20 > full reconfiguration of each PE to get to the same level of BGP path=20 > redundancy reception. >=20 > - Addition and deletion of new service POP both planned and unplanned = > require full reconfiguration of each PE to get to the same level of = BGP=20 > path redundancy reception. >=20 > - POPs which do not have local exit ASBRs and which do not leak next=20 > hops from core to POP area in the IGP even if given opportunity to=20 > receive _all_ external paths still have no visibility into the closet=20 > exit ASBR in the domain as ABRs would typically depending on the IGP=20 > selection and area type shield them from domain wide flooding=20 > information. Therefor those PEs will still remain selecting random = paths=20 > unless the proposal would also include static best path selection on=20 > such PEs based on RT. >=20 > * The draft says: >=20 > We make the assumption that complete Internet routing > information is available at every ASBR. If the local ASBR does not > have reachibility to the relevant prefixes (or the ASBR itself is = not > available), traffic should use the closest (in terms of IGP metric) > egress. >=20 > It would be interesting to see under what network conditions one could = > assure that that every ASBR in the network contains complete Internet=20 > routing. Then I would like to see prove on how using static RT mapping = > to one's preference of some day assures reception and selection of = paths=20 > which could be categorized as "closest (in terms of IGP metric) = egress".=20 > Provided example of 3 ASBRs located on three continents of the world = is=20 > rather unreal considering today's network topologies where number of=20 > ASBRs or IX interconnects very often reaches much larger numbers. >=20 > * The title of the draft should reflect that the proposal does not=20 > provide, a solution for "optimal" route reflection. The draft = describes=20 > a solution for "operator's statically configured ASBR path = preferences".=20 > Those two are quite dis-joined solutions. While perhaps under some=20 > scenarios the end result may be the same at a given point of time = there=20 > is no guarantee that such result will stay as such during day to day=20 > network operation. >=20 > * RT Constrain as proposed, implemented and deployed today has been=20 > designed to express a VPN membership rules as an base object. While=20 > there were some attempts to further divide this to be on per AFI/SAFI=20 > basis RT Constrain authors came to the conclusion that those attempts=20 > have no practical justification. In this proposal use of RT constrain=20 > filtering would however result in the same exit ASBR preference to be=20 > applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It = is=20 > already well known fact in operation today that optimal/closest exit=20 > preferences for IPv4 unicast do not match in many networks the=20 > optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs. = > It would be interesting how authors of the proposed draft are going to = > address this point going forward. >=20 > *** >=20 > Now let me take a moment to provide few points on number of advantages = > of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 = as=20 > compared with the above document: >=20 > * IDR WG draft does not require any manual static configuration of = path=20 > preferences - all required information is already present today on the = > RR and can be readily used. >=20 > * IDR WG draft can use add-paths to send more then best optimal path=20 > from RR to the RR client - per clients preference >=20 > * IDR WG draft dynamically recalculates optimal/closest IGP metric = exist=20 > point or points for each client and group of clients when ASBR=20 > add/withdraw BGP routes or when IGP topology changes >=20 > * IDR WG draft provides ways to dynamically group clients based on = their=20 > common POP location / IGP area without any operator's configuration=20 > burden on RR >=20 > * IDR WG draft works equally well in normal IPv4/IPv6 networks as well = > as with some form of tunneled networks without putting any requirement = > on forwarding paradigm selection in the network >=20 > * It works in the same way for any AFI/SAFI and independently = guarantees=20 > calculation of optimal/closest exit points for IPv4, IPv4+label or = IPv6=20 > paths as well as their distribution to the clients. >=20 > * IDR WG document provides ability for virtual RR placement in any IGP = > network node location without any physical reconnection required. Such = > provision is not addressed in the above document. >=20 > Best regards, > R. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ------------------------------ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr End of Idr Digest, Vol 86, Issue 3 ********************************** From vjoseph@juniper.net Mon Jun 6 07:22:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8C711E8151 for ; Mon, 6 Jun 2011 07:22:36 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuUZS8UxgCNz for ; Mon, 6 Jun 2011 07:22:34 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9748411E8145 for ; Mon, 6 Jun 2011 07:22:33 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTeziqfGRcR88FtuRdILN1aes59eHv0+X@postini.com; Mon, 06 Jun 2011 07:22:33 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Mon, 6 Jun 2011 07:20:19 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 15:20:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2011 15:19:58 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Idr Digest, Vol 86, Issue 5 Thread-Index: AcwkU5CFD3qsc/cwReWrcH4AO8GLFgAAH/vw References: From: Vinod Joseph To: X-OriginalArrivalTime: 06 Jun 2011 14:20:03.0229 (UTC) FILETIME=[D3919CD0:01CC2454] Subject: Re: [Idr] Idr Digest, Vol 86, Issue 5 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:22:36 -0000 Robert, Glad that you agree that SPF on RRs as per your draft is not the way and = that alternates are the need of the hour. Let me clarify this clearly. The proposed draft provides the PE to = indicate a list of affinities for ASBRs. It may choose to use the (1) = closest based on the IGP Metric (2) Optimal NH based on traffic flow = requirements that mandate that exit for certain PEs/POPs use a given set = of ASBRs only (3) offload any overhead from the RR (4) Support other AF = in addition to IPv4 (5) Use existing BGP state machinery that has been = in use for ages (6) Offer extreme flexibility in control max number of = paths per RT (7) Use individual RTs per RR to choose paths from a given = RR and so on... Hope this makes clear for all that this proposal has distinct advantages = when compared to the drafts you have mentioned. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = idr-request@ietf.org Sent: 06 June 2011 15:11 To: idr@ietf.org Subject: Idr Digest, Vol 86, Issue 5 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/idr Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Idr mailing list submissions to idr@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/idr or, via email, send a message with subject or body 'help' to idr-request@ietf.org You can reach the person managing the list at idr-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Idr digest..." Today's Topics: 1. Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Robert Raszuk) 2. Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Vinod Joseph) ---------------------------------------------------------------------- Message: 1 Date: Sun, 05 Jun 2011 23:24:38 +0200 From: Robert Raszuk To: idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Message-ID: <4DEBF416.5060907@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Vinod, Let me also describe how all goals of your draft are met by IDR WG doc=20 as well as by associated with it Next-Hop SAFI draft=20 (draft-varlashkin-bgp-nh-cost-01) without any need for using SPF on the=20 RRs. Imagine you have number of PEs which per operator's logic know their=20 exit preference. Using new NH-SAFI they can idicate to RR their own=20 local metric to each of available next hop. If one or N of those paths=20 with previously advertised next hops goes away RR will immediately=20 replace it with new set of available paths. This is simplest form of local operator decision on what is the order of = paths in the network yet number of paths received by PE is decoupled=20 from the preference (unlike in your draft). It is also robust as at any=20 point it will not result in the customer's outage. Here I would like to thank you for highlighting within our discussion=20 that PE driven provider's optimal path selection is requested by some=20 operators. This will clearly help to progress=20 draft-varlashkin-bgp-nh-cost-01 and it's implementations further and it=20 offers a very good tool to accomplish such requirement. Best regards, R. ------------------------------ Message: 2 Date: Mon, 6 Jun 2011 15:09:16 +0100 From: Vinod Joseph To: Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Message-ID: <5DD781A4BE13384A900438DF0608972C06996C95@emailemea4.jnpr.net> Content-Type: text/plain; charset=3D"iso-8859-1" Robert, More inline -=20 Up front to make it very clear for all readers can authors explicitly=20 confirm that the applicability of this draft is only limited to=20 networks which use some form of tunneling (for example: MPLS) between=20 each PE and ASBRs ? Vinod# Yes POPs which do not have local exit ASBRs and which do not leak next=20 hops from core to POP area in the IGP even if given opportunity to=20 receive _all_ external paths still have no visibility into the closet=20 exit ASBR in the domain as ABRs would typically depending on the IGP=20 selection and area type shield them from domain wide flooding=20 information. Therefor those PEs will still remain selecting random=20 paths unless the proposal would also include static best path=20 selection on such PEs based on RT. Vinod# Can you explain this, not sure whether I follow your question? RT Constrain as proposed, implemented and deployed today has been=20 designed to express a VPN membership rules as an base object. While=20 there were some attempts to further divide this to be on per AFI/SAFI=20 basis RT Constrain authors came to the conclusion that those attempts=20 have no practical justification. In this proposal use of RT constrain=20 filtering would however result in the same exit ASBR preference to be=20 applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. Vinod# Why is that the case? RTs would control the set of paths that a = PE would receive. However the choice of which of these to pick could be = different for IPv4 and IPv6. However if the desire is to have different sets for IPv4 and different = sets for IPv6 then one way to solve this is to have different RTs for = IPv4 and IPv6. With this model if a PE has both IPv4 and IPv6 routes, it = would use different RTs for v4 and v6. In the case of VPNs, some vendors said that they wanted to reuse the = same RT for IPv4 and IPv6 VPNs and yet not send IPv4 routes to an IPv6 = only PE, for example. Hence there was discussion on AFI/SAFI granularity = for RT constrain. For the purposes of this draft the solution is = probably much simpler. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks?????????????????????????????????????????????????????????????????= ?? M: +44 (0) 7500 835 876 E:?vjoseph@juniper.net ? -----Original Message----- From: Vinod Joseph=20 Sent: 05 June 2011 20:58 To: idr@ietf.org Subject: RE: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Robert, The objective of the draft is to provide closest exit routing based on = the operators preference. Let me answer each of the comments inline: > It does it in pure static way putting all burden of what can be=20 automated into the operator's NOC. Note that all information required=20 for optimal path selection is already present on RR without any need for = operational configuration burden today. Vinod# You rightly said that RT constrain and Route Targets have been = used for a while now. The idea of this draft is to ensure that existing = BGP machinery successfully used in the context of other address = families, is used for IPv4. Policy control on the list of paths needed = is indicated by the PE through the use of RT constrain, and only = prefixes/paths that match the list of RTs specified are announced by the = RR, and the PEs do the best path calculation. It is arguable that policy = control via RT constrain adds operational burden - since the use of RT = and RT constrain have been used on other address families for ages as = you mentioned. The advantage here is that the RR can be completely taken = out of the picture as far as the closest or optimal path calculation = goes. The networks topologies change dynamically which will not be=20 reflected in the static RT based preference. Vinod# Let me put it this way, an operator may prefer a list of RTs and = not just a single RT - if we assume a single RT maps to a single ASBR, = to build resiliency. The objective is clear - provide the operator with = an approach to selectively choose the best path, and also indicate a = list of affinities (list of RTs) that a PE is interested in. It is also = possible to extend the scheme where all ASBRs within a region =3D a = single RT. Therefore there is flexibility. Primarily this draft does not = (1) break the use of BGP Peer groups (2) cause network churn if there is = an IGP change, since we are not using an SPF instance per PE.=20 - Addition and deletion of new ASBR both planned and unplanned require=20 full reconfiguration of each PE to get to the same level of BGP path=20 redundancy reception. Vinod# Like I mentioned, planning for resiliency and allocation of RTs = are flexible. It is not mandatory to have a single ASBR be allotted a = single RT, multiple ASBRs may share the same RT. > POPs which do not have local exit ASBRs and which do not leak next=20 hops from core to POP area in the IGP even if given opportunity to=20 receive _all_ external paths still have no visibility into the closet=20 exit ASBR in the domain as ABRs would typically depending on the IGP=20 selection and area type shield them from domain wide flooding=20 information. Therefor those PEs will still remain selecting random paths = unless the proposal would also include static best path selection on=20 such PEs based on RT. We make the assumption that complete Internet routing information is available at every ASBR. If the local ASBR does not have reachibility to the relevant prefixes (or the ASBR itself is = not available), traffic should use the closest (in terms of IGP metric) egress. It would be interesting to see under what network conditions one could=20 assure that that every ASBR in the network contains complete Internet=20 routing. Then I would like to see prove on how using static RT mapping=20 to one's preference of some day assures reception and selection of paths = which could be categorized as "closest (in terms of IGP metric) egress". = Provided example of 3 ASBRs located on three continents of the world is=20 rather unreal considering today's network topologies where number of=20 ASBRs or IX interconnects very often reaches much larger numbers. Vinod# The draft also talks about scenarios of POPs with ASBRs having = only partial routes and not just complete routes. Once again this brings = us back to the original point elaborated above. An operator does not = need to build a model where each ASBR belongs to an individual RT. If my = objective is to use the local ASBR (having only 1000 prefixes for = instance) for known prefixes, and another ASBR(s) in a given region/POPs = (having full routes) - I would need to add in appropriate RT(s) for = signalling interest. Do take note, that the draft talks about the = possibility of indicating max-no-of-paths per RT - in the event of a PE = unable to take many a path advertised via ADD-PATH or even if the = constraints on path selection is more lenient. Flexibility is the key = here. * The title of the draft should reflect that the proposal does not=20 provide, a solution for "optimal" route reflection. The draft describes=20 a solution for "operator's statically configured ASBR path preferences". = Those two are quite dis-joined solutions. While perhaps under some=20 scenarios the end result may be the same at a given point of time there=20 is no guarantee that such result will stay as such during day to day=20 network operation. Vinod# Optimal route reflection is what the operator deems as optimal. = This draft provides the ability to instruct the RR to announce only a = set of paths that it considers optimal and choose between them. In other = words optimal is more relevant to the end user (PE) and not the RR. So = if the PE wants to use a path with the closest IGP metric, it indicates = the RR to only send paths that match a given RT.=20 * IDR WG draft does not require any manual static configuration of path=20 preferences - all required information is already present today on the=20 RR and can be readily used. * IDR WG draft can use add-paths to send more then best optimal path=20 from RR to the RR client - per clients preference Vinod# Same applies here. Key in this proposal (1) do not break the use = of BGP Peer groups (2) No churn on the RR re-calculating best path on = behalf of each PE in case of IGP fluctuations (3) More flexibility in = indicating the paths that are needed (4) max number of paths per RT can = be signalled (5) Each RR can be allocated an RT, and if a PE signals = only that RT in the RT constrain, then the RR calculated best path only = (default behaviour) is announced (6) Existing BGP machinery is re-used = for IPv4. * IDR WG draft dynamically recalculates optimal/closest IGP metric exist = point or points for each client and group of clients when ASBR=20 add/withdraw BGP routes or when IGP topology changes Vinod# IGP Churn impacting re-calculation?? * IDR WG draft provides ways to dynamically group clients based on their = common POP location / IGP area without any operator's configuration=20 burden on RR Vinod# Not just the ASBR with the closest IGP metric, but any affinity = to any combination of ASBR(s) can be chosen based on the policy of the = POP/individual PE can be deployed.=20 * IDR WG draft works equally well in normal IPv4/IPv6 networks as well=20 as with some form of tunneled networks without putting any requirement=20 on forwarding paradigm selection in the network Vinod# Not sure whether I follow this. The proposed draft focuses on = clearing the core or P routers (if you may) to steer clear of BGP = routing - for hot potato routing. But nothing stops an implementation = from using that. * It works in the same way for any AFI/SAFI and independently guarantees = calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6=20 paths as well as their distribution to the clients. Vinod# Per AF based policies can be used.=20 * IDR WG document provides ability for virtual RR placement in any IGP=20 network node location without any physical reconnection required. Such=20 provision is not addressed in the above document. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks?????????????????????????????????????????????????????????????????= ?? M: +44 (0) 7500 835 876 E:?vjoseph@juniper.net ? -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = idr-request@ietf.org Sent: 05 June 2011 20:00 To: idr@ietf.org Subject: Idr Digest, Vol 86, Issue 3 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/idr Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Idr mailing list submissions to idr@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/idr or, via email, send a message with subject or body 'help' to idr-request@ietf.org You can reach the person managing the list at idr-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Idr digest..." Today's Topics: 1. draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Robert Raszuk) 2. Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt (Jeff Tantsura) ---------------------------------------------------------------------- Message: 1 Date: Sun, 05 Jun 2011 00:51:57 +0200 From: Robert Raszuk To: "idr@ietf.org List" Subject: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Message-ID: <4DEAB70D.10403@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi, Attracted by the title I could not resit to read this draft. Here are=20 some of the comments and questions I have regarding the document. * Up front to make it very clear for all readers can authors explicitly=20 confirm that the applicability of this draft is only limited to networks = which use some form of tunneling (for example: MPLS) between each PE and = ASBRs ? * The idea of community based route selection on RRs is nothing new.=20 Using RT extended community as well as RT Constrain while does automates = the preference push from PE to RR to limit number of paths to be=20 received. However if also comes along with the following issues: - It does it in pure static way putting all burden of what can be=20 automated into the operator's NOC. Note that all information required=20 for optimal path selection is already present on RR without any need for = operational configuration burden today. - The networks topologies change dynamically which will not be=20 reflected in the static RT based preference. - Addition and deletion of new ASBR both planned and unplanned require = full reconfiguration of each PE to get to the same level of BGP path=20 redundancy reception. - Addition and deletion of new service POP both planned and unplanned=20 require full reconfiguration of each PE to get to the same level of BGP=20 path redundancy reception. - POPs which do not have local exit ASBRs and which do not leak next=20 hops from core to POP area in the IGP even if given opportunity to=20 receive _all_ external paths still have no visibility into the closet=20 exit ASBR in the domain as ABRs would typically depending on the IGP=20 selection and area type shield them from domain wide flooding=20 information. Therefor those PEs will still remain selecting random paths = unless the proposal would also include static best path selection on=20 such PEs based on RT. * The draft says: We make the assumption that complete Internet routing information is available at every ASBR. If the local ASBR does not have reachibility to the relevant prefixes (or the ASBR itself is = not available), traffic should use the closest (in terms of IGP metric) egress. It would be interesting to see under what network conditions one could=20 assure that that every ASBR in the network contains complete Internet=20 routing. Then I would like to see prove on how using static RT mapping=20 to one's preference of some day assures reception and selection of paths = which could be categorized as "closest (in terms of IGP metric) egress". = Provided example of 3 ASBRs located on three continents of the world is=20 rather unreal considering today's network topologies where number of=20 ASBRs or IX interconnects very often reaches much larger numbers. * The title of the draft should reflect that the proposal does not=20 provide, a solution for "optimal" route reflection. The draft describes=20 a solution for "operator's statically configured ASBR path preferences". = Those two are quite dis-joined solutions. While perhaps under some=20 scenarios the end result may be the same at a given point of time there=20 is no guarantee that such result will stay as such during day to day=20 network operation. * RT Constrain as proposed, implemented and deployed today has been=20 designed to express a VPN membership rules as an base object. While=20 there were some attempts to further divide this to be on per AFI/SAFI=20 basis RT Constrain authors came to the conclusion that those attempts=20 have no practical justification. In this proposal use of RT constrain=20 filtering would however result in the same exit ASBR preference to be=20 applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It is=20 already well known fact in operation today that optimal/closest exit=20 preferences for IPv4 unicast do not match in many networks the=20 optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs.=20 It would be interesting how authors of the proposed draft are going to=20 address this point going forward. *** Now let me take a moment to provide few points on number of advantages=20 of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 as = compared with the above document: * IDR WG draft does not require any manual static configuration of path=20 preferences - all required information is already present today on the=20 RR and can be readily used. * IDR WG draft can use add-paths to send more then best optimal path=20 from RR to the RR client - per clients preference * IDR WG draft dynamically recalculates optimal/closest IGP metric exist = point or points for each client and group of clients when ASBR=20 add/withdraw BGP routes or when IGP topology changes * IDR WG draft provides ways to dynamically group clients based on their = common POP location / IGP area without any operator's configuration=20 burden on RR * IDR WG draft works equally well in normal IPv4/IPv6 networks as well=20 as with some form of tunneled networks without putting any requirement=20 on forwarding paradigm selection in the network * It works in the same way for any AFI/SAFI and independently guarantees = calculation of optimal/closest exit points for IPv4, IPv4+label or IPv6=20 paths as well as their distribution to the clients. * IDR WG document provides ability for virtual RR placement in any IGP=20 network node location without any physical reconnection required. Such=20 provision is not addressed in the above document. Best regards, R. ------------------------------ Message: 2 Date: Sat, 4 Jun 2011 22:05:08 -0400 From: Jeff Tantsura To: "raszuk@cisco.com" Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt Message-ID: <94E61C27-F386-4EA7-B1CD-60A7619D3874@ericsson.com> Content-Type: text/plain; charset=3D"us-ascii" +1 Regards, Jeff On Jun 4, 2011, at 15:51, "Robert Raszuk" wrote: > Hi, >=20 > Attracted by the title I could not resit to read this draft. Here are=20 > some of the comments and questions I have regarding the document. >=20 > * Up front to make it very clear for all readers can authors = explicitly=20 > confirm that the applicability of this draft is only limited to = networks=20 > which use some form of tunneling (for example: MPLS) between each PE = and=20 > ASBRs ? >=20 > * The idea of community based route selection on RRs is nothing new.=20 > Using RT extended community as well as RT Constrain while does = automates=20 > the preference push from PE to RR to limit number of paths to be=20 > received. However if also comes along with the following issues: >=20 > - It does it in pure static way putting all burden of what can be=20 > automated into the operator's NOC. Note that all information required=20 > for optimal path selection is already present on RR without any need = for=20 > operational configuration burden today. >=20 > - The networks topologies change dynamically which will not be=20 > reflected in the static RT based preference. >=20 > - Addition and deletion of new ASBR both planned and unplanned = require=20 > full reconfiguration of each PE to get to the same level of BGP path=20 > redundancy reception. >=20 > - Addition and deletion of new service POP both planned and unplanned = > require full reconfiguration of each PE to get to the same level of = BGP=20 > path redundancy reception. >=20 > - POPs which do not have local exit ASBRs and which do not leak next=20 > hops from core to POP area in the IGP even if given opportunity to=20 > receive _all_ external paths still have no visibility into the closet=20 > exit ASBR in the domain as ABRs would typically depending on the IGP=20 > selection and area type shield them from domain wide flooding=20 > information. Therefor those PEs will still remain selecting random = paths=20 > unless the proposal would also include static best path selection on=20 > such PEs based on RT. >=20 > * The draft says: >=20 > We make the assumption that complete Internet routing > information is available at every ASBR. If the local ASBR does not > have reachibility to the relevant prefixes (or the ASBR itself is = not > available), traffic should use the closest (in terms of IGP metric) > egress. >=20 > It would be interesting to see under what network conditions one could = > assure that that every ASBR in the network contains complete Internet=20 > routing. Then I would like to see prove on how using static RT mapping = > to one's preference of some day assures reception and selection of = paths=20 > which could be categorized as "closest (in terms of IGP metric) = egress".=20 > Provided example of 3 ASBRs located on three continents of the world = is=20 > rather unreal considering today's network topologies where number of=20 > ASBRs or IX interconnects very often reaches much larger numbers. >=20 > * The title of the draft should reflect that the proposal does not=20 > provide, a solution for "optimal" route reflection. The draft = describes=20 > a solution for "operator's statically configured ASBR path = preferences".=20 > Those two are quite dis-joined solutions. While perhaps under some=20 > scenarios the end result may be the same at a given point of time = there=20 > is no guarantee that such result will stay as such during day to day=20 > network operation. >=20 > * RT Constrain as proposed, implemented and deployed today has been=20 > designed to express a VPN membership rules as an base object. While=20 > there were some attempts to further divide this to be on per AFI/SAFI=20 > basis RT Constrain authors came to the conclusion that those attempts=20 > have no practical justification. In this proposal use of RT constrain=20 > filtering would however result in the same exit ASBR preference to be=20 > applied for IPv4 as to the IPv6 with or without labels AFI/SAFIs. It = is=20 > already well known fact in operation today that optimal/closest exit=20 > preferences for IPv4 unicast do not match in many networks the=20 > optimal/closest exit preferences for IPv6 or for IPv4+label AFI/SAFIs. = > It would be interesting how authors of the proposed draft are going to = > address this point going forward. >=20 > *** >=20 > Now let me take a moment to provide few points on number of advantages = > of the IDR WG document draft-ietf-idr-bgp-optimal-route-reflection-00 = as=20 > compared with the above document: >=20 > * IDR WG draft does not require any manual static configuration of = path=20 > preferences - all required information is already present today on the = > RR and can be readily used. >=20 > * IDR WG draft can use add-paths to send more then best optimal path=20 > from RR to the RR client - per clients preference >=20 > * IDR WG draft dynamically recalculates optimal/closest IGP metric = exist=20 > point or points for each client and group of clients when ASBR=20 > add/withdraw BGP routes or when IGP topology changes >=20 > * IDR WG draft provides ways to dynamically group clients based on = their=20 > common POP location / IGP area without any operator's configuration=20 > burden on RR >=20 > * IDR WG draft works equally well in normal IPv4/IPv6 networks as well = > as with some form of tunneled networks without putting any requirement = > on forwarding paradigm selection in the network >=20 > * It works in the same way for any AFI/SAFI and independently = guarantees=20 > calculation of optimal/closest exit points for IPv4, IPv4+label or = IPv6=20 > paths as well as their distribution to the clients. >=20 > * IDR WG document provides ability for virtual RR placement in any IGP = > network node location without any physical reconnection required. Such = > provision is not addressed in the above document. >=20 > Best regards, > R. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ------------------------------ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr End of Idr Digest, Vol 86, Issue 3 ********************************** ------------------------------ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr End of Idr Digest, Vol 86, Issue 5 ********************************** From raszuk@cisco.com Mon Jun 6 07:36:04 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9038011E814D for ; Mon, 6 Jun 2011 07:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPlym-MBLpZc for ; Mon, 6 Jun 2011 07:36:04 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 287A011E8146 for ; Mon, 6 Jun 2011 07:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1280; q=dns/txt; s=iport; t=1307370964; x=1308580564; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=nfcYbK5i6DQKo7CWl+pk3vZ4Xm91GeQfbb3QuWzdJtM=; b=D3ccEu4n65DUxVQq1KBZHCXClJ1ICDKrjFQeALqPW5ZzBKiRR4weCndR FA7SBlX7vMGHayn9c1gTw61n/p8sLBG5cf+k/q8MjNKdHHAUsbtsvrj1n SKBrGD2YQTnqV7q0BsgFSdx8cihqXM9ZkgMgEhNsB1eaOLq+BzOCbnePd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEIAJHk7E2rRDoH/2dsb2JhbABTmByOIHeIcaNBgnwPAZo+hiEEkHmESIp0 X-IronPort-AV: E=Sophos;i="4.65,326,1304294400"; d="scan'208";a="331024645" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 06 Jun 2011 14:36:03 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p56Ea2B5020853 for ; Mon, 6 Jun 2011 14:36:03 GMT Message-ID: <4DECE5D1.5090005@cisco.com> Date: Mon, 06 Jun 2011 16:36:01 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Idr Digest, Vol 86, Issue 5 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:36:04 -0000 Vinod, > Glad that you agree that SPF on RRs as per your draft is not the way No. I do not agree with that. It is the way. RR is just a computer. Computers are build to compute not to push the work further. > and that alternates are the need of the hour. My point was to indicate that all alternatives you list below are already possible with IDR WG doc + draft-varlashkin-bgp-nh-cost and all without any need for overhead of managing RTs for IP unicast or multicast routes. Thx, R. > Let me clarify this clearly. The proposed draft provides the PE to > indicate a list of affinities for ASBRs. It may choose to use the (1) > closest based on the IGP Metric (2) Optimal NH based on traffic flow > requirements that mandate that exit for certain PEs/POPs use a given > set of ASBRs only (3) offload any overhead from the RR (4) Support > other AF in addition to IPv4 (5) Use existing BGP state machinery > that has been in use for ages (6) Offer extreme flexibility in > control max number of paths per RT (7) Use individual RTs per RR to > choose paths from a given RR and so on... > > Hope this makes clear for all that this proposal has distinct > advantages when compared to the drafts you have mentioned. > > > Regards Vinod Joseph From ilya@nobulus.com Mon Jun 6 08:25:38 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D2E21F8437 for ; Mon, 6 Jun 2011 08:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T-It5X6fwLv for ; Mon, 6 Jun 2011 08:25:38 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id B847A21F8436 for ; Mon, 6 Jun 2011 08:25:37 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id D92F21712D; Mon, 6 Jun 2011 17:25:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sLNpzqdWd9Zq; Mon, 6 Jun 2011 17:25:32 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:1198:1073:b5b7:33f9]) by nobulus.com (Postfix) with ESMTPA id 896ED17478; Mon, 6 Jun 2011 17:25:30 +0200 (CEST) Message-ID: <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> From: "iLya" To: "Vinod Joseph" , References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> Date: Mon, 6 Jun 2011 17:25:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 15:25:38 -0000 Vinod, looking at yours and Robert's fast-paced conversation I didn't want to interfere in the middle, but your latest mail seems like appropriate point for me to respond. Please see inline. -------------------------------------------------- > Let me clarify this clearly. The proposed draft provides the PE to > indicate a list of affinities for ASBRs. It may choose to use the (1) > closest based on the IGP Metric (2) Optimal NH based on traffic flow > requirements that mandate that exit for certain PEs/POPs use a given set > of ASBRs only (3) offload any overhead from the RR (4) Support other AF in > addition to IPv4 (5) Use existing BGP state machinery that has been in use > for ages (6) Offer extreme flexibility in control max number of paths per > RT (7) Use individual RTs per RR to choose paths from a given RR and so > on... > NH SAFI would allow you to do all of the above without need for ADD-PATH unless hierarchical route-reflectors are involved. An operator could simply configure routers to send administrative cost to next-hops rather then the one based on IGP. Reading further you draft, I do not agree that contemporary ASBR's are suitable for performing route-reflection - they do have enough space for storing multiple RIB views, but their computational power is only fraction of what's available on the route reflectors for fraction of the cost. Now a quote from section 3 of your draft: "since multiple paths are available on the PE and the decision process can now be re-run on the PE itself." That seems to imply either modification of the BGP selection process on the PE routers (not good), or use of policies to alter locally-significant preference (performance penalty, and recipe for inconsistent routing), or depreving PE routers from guaranteed connectivity to certain prefixes if they happen to be learned not via ASBR's that mark routes with RT that those PE are interested in. Also, it's likely to be the case that overall number of AS exit points (==potential next-hops) is higher than number of exit points where certain prefixes are learned (e.g. some US-based network may or may not have direct presence at european exchange point), in this case your solution will provide suboptimum routing (let me know if you'd like me to elaborate on this). If operators would like to change exit point preferences then two existing drafts already have two solutions - either using angular metric or by using NH SAFI, and without limitations described above. Kind regards, iLya From vjoseph@juniper.net Mon Jun 6 11:22:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E571C11E81BF for ; Mon, 6 Jun 2011 11:22:49 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZQ6pRpO8RwG for ; Mon, 6 Jun 2011 11:22:49 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id BB30211E81C6 for ; Mon, 6 Jun 2011 11:22:48 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTe0a8gxLWNfTPwS3id3GnuxQj9lP/vVT@postini.com; Mon, 06 Jun 2011 11:22:48 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Mon, 6 Jun 2011 11:21:27 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 19:21:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2011 19:21:19 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: AcwkXf8Jv3Qfi3JRTiOoqdLnuhvoPQAFWGUg References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> From: Vinod Joseph To: iLya , X-OriginalArrivalTime: 06 Jun 2011 18:21:25.0361 (UTC) FILETIME=[8B979610:01CC2476] Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 18:22:50 -0000 Ilya, One of the aspects that this proposal will address is the use of = hierarchical Route Reflectors. On your points: "Reading further you draft, I do not agree that contemporary ASBR's are=20 suitable for performing route-reflection - they do have enough space for = storing multiple RIB views, but their computational power is only = fraction=20 of what's available on the route reflectors for fraction of the cost." Vinod# The intent of this has been misunderstood. There was only a = representation of ASBRs performing route reflection as an approach that = some carriers may use to address the hot potato routing issue. We are = not proposing that this is a solution in the draft. So let us clearly = remove this from the discussion Your draft does propose the need for a new BGP capability, our proposal = intends to re-use existing BGP machinery for IPv4/V6 (RT/RT Constrain) = and avoid much re-invention to the BGP state machinery. Depending on the scale and capability of the PE, only a given number of = ASBR paths can be indicated as acceptable. For instance a PE may = indicate a preference of only 3 paths per RT. Whenever a path is = withdrawn, the RR would announce an additional path (if available within = the context of the RT signalled) to the PE.=20 The proposal also makes way for a mechanism where a PE can signal = interest in 2 Route targets and announce a special RT which is allocated = on a per RR. This will provide more flexibility, wherein the RR would = announce "N" number of paths for the two RTs, and calculate the best = path for all other prefixes (default scheme) since the PE has sent = interest in the RT allocated to a given RR. This provides flexibility = for path selection and also provides an alternate for resiliency. = Therefore there cannot be a permanent outage. RT constrain also provides an optimal way of automatically filtering = prefixes between RRs which have clients that are not interested in = certain RTs.=20 Why do you see the PE performing a best path calculation a problem? The = draft has enough methods to providing optimal routing from a PE's = standpoint without too much burden on the control plane, and I have = explained this above. There is an added advantage by doing this as well, = if a PE has more than one path locally available, it would provide = quicker convergence locally, rather than waiting for the RR to pick the = second best and announce it back to PEs. Coming back to your comment in the NH SAFI draft - Section A3. As addition to ADDPATH a mechanism could be devised that would allow RR2 to learn how many alternative routes does it need to send to RR1. For example, if NetA would also be connected to R9 (not shown) but all clients of RR1 prefer R7 as exit point and R9 as next-best, then there is no need for RR2 to send NetA routes with next-hop R8 to RR1. Vinod# This is addressed in our draft and provides a solution = already. One of the advantages: This draft proposes a scheme where each PE in a = POP may use a separate ASBR for exit, by means of announcing interest in = specific Route Targets. In other words an operator can use certain ASBRs = for certain PEs that are within the same POP, as primary exit points. = Even if you would cost an ASBR administratively, can you elaborate how = would influence one PE within the same POP as the ASBR to choose the = local ASBR and another PE to use an ASBR in a remote POP? Since the RR = is doing the best path calculation in your case? Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: iLya [mailto:ilya@nobulus.com]=20 Sent: 06 June 2011 16:25 To: Vinod Joseph; idr@ietf.org Subject: Re: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) Vinod, looking at yours and Robert's fast-paced conversation I didn't want to=20 interfere in the middle, but your latest mail seems like appropriate = point=20 for me to respond. Please see inline. -------------------------------------------------- > Let me clarify this clearly. The proposed draft provides the PE to=20 > indicate a list of affinities for ASBRs. It may choose to use the (1)=20 > closest based on the IGP Metric (2) Optimal NH based on traffic flow=20 > requirements that mandate that exit for certain PEs/POPs use a given = set=20 > of ASBRs only (3) offload any overhead from the RR (4) Support other = AF in=20 > addition to IPv4 (5) Use existing BGP state machinery that has been in = use=20 > for ages (6) Offer extreme flexibility in control max number of paths = per=20 > RT (7) Use individual RTs per RR to choose paths from a given RR and = so=20 > on... > NH SAFI would allow you to do all of the above without need for ADD-PATH = unless hierarchical route-reflectors are involved. An operator could = simply=20 configure routers to send administrative cost to next-hops rather then = the=20 one based on IGP. Reading further you draft, I do not agree that contemporary ASBR's are=20 suitable for performing route-reflection - they do have enough space for = storing multiple RIB views, but their computational power is only = fraction=20 of what's available on the route reflectors for fraction of the cost. Now a quote from section 3 of your draft: "since multiple paths are available on the PE and the decision process can now be re-run on the PE itself." That seems to imply either modification of the BGP selection process on = the=20 PE routers (not good), or use of policies to alter locally-significant=20 preference (performance penalty, and recipe for inconsistent routing), = or=20 depreving PE routers from guaranteed connectivity to certain prefixes if = they happen to be learned not via ASBR's that mark routes with RT that = those=20 PE are interested in. Also, it's likely to be the case that overall = number=20 of AS exit points (=3D=3Dpotential next-hops) is higher than number of = exit=20 points where certain prefixes are learned (e.g. some US-based network = may or=20 may not have direct presence at european exchange point), in this case = your=20 solution will provide suboptimum routing (let me know if you'd like me = to=20 elaborate on this). If operators would like to change exit point preferences then two = existing=20 drafts already have two solutions - either using angular metric or by = using=20 NH SAFI, and without limitations described above. Kind regards, iLya =20 From raszuk@cisco.com Mon Jun 6 11:41:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695CB11E818E for ; Mon, 6 Jun 2011 11:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaTs-WSZ4nqH for ; Mon, 6 Jun 2011 11:41:04 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED0111E8196 for ; Mon, 6 Jun 2011 11:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=648; q=dns/txt; s=iport; t=1307385663; x=1308595263; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=KC38TjbH4jr5I8ve4ezvGgYAf++lXkXJ0aRPbluvKPE=; b=T76pHML/eupeim2WH7x8XOd3M3Yp7Gwy0Dnz34faa2XmCnyTlEGD986+ 2M51Lilvc4GPTel/yZnIjkURzyeTE+ovSI5caoMuUg67Gsuwk4vYTA1bv ++vbdPsfcW1QQQdSNXe+dlWrN6+2OiHctSyYz071Z4ys3dDQ2/AZ8Q90b c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkHAPkd7U2rRDoJ/2dsb2JhbABTmAWOIXeIcaJugnwPAZpuhiEEkHmESIp0 X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208";a="331213111" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 06 Jun 2011 18:41:03 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p56If2Gi014442 for ; Mon, 6 Jun 2011 18:41:03 GMT Message-ID: <4DED1F50.6090507@cisco.com> Date: Mon, 06 Jun 2011 20:41:20 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 18:41:05 -0000 Vinod, > special RT which is allocated on a per RR. Please provide a quote from RFC4684 which would describe the concept of special RT which is allocated on a per RR basis as well as expected handling of this special RT by RR. What device allocates this special RT ? What is the meaning of this special RT ? Your explanations are very vague and not on the topic of the questions asked. Please kindly re-explain how using your solution PE will still get some paths even in the event of said PEs preferring subset of all available paths as indicated by the set of RTs and this subset of paths is no longer available. R. From ilya@nobulus.com Mon Jun 6 11:49:23 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB411E81A9 for ; Mon, 6 Jun 2011 11:49:23 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4tJvN2jHWpj for ; Mon, 6 Jun 2011 11:49:23 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 6569111E8150 for ; Mon, 6 Jun 2011 11:49:22 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 944561744E; Mon, 6 Jun 2011 20:49:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2h8f6BZ5yVsl; Mon, 6 Jun 2011 20:49:18 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id B32E517473; Mon, 6 Jun 2011 20:49:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> Date: Mon, 6 Jun 2011 20:49:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> To: Vinod Joseph X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 18:49:23 -0000 On Jun 6, 2011, at 20:21 , Vinod Joseph wrote: > Depending on the scale and capability of the PE, only a given number = of ASBR paths can be indicated as acceptable. For instance a PE may = indicate a preference of only 3 paths per RT. Whenever a path is = withdrawn, the RR would announce an additional path (if available within = the context of the RT signalled) to the PE.=20 >=20 Let's get specific. Consider 10 ASBR's in Europe and 10 in USA, and a = bunch of PE's in each of these regions. Closest (according to current = active) topology exit to reach foreign network is required. How many = RT's do we need to cover this case, how many PATHs should RR advertise = to PE, and what happens when this RR goes away? next round: what will be = behaviour when a prefix learned via an ASBR that does not advertise RT = in which PE is interested? Kind regards, iLya From vjoseph@juniper.net Mon Jun 6 15:43:40 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D643E21F8476 for ; Mon, 6 Jun 2011 15:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M41916khAgxQ for ; Mon, 6 Jun 2011 15:43:39 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id E9A5721F8475 for ; Mon, 6 Jun 2011 15:43:32 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTe1YFBWZEMgOUO4AON7W2VYUqFxqC0Du@postini.com; Mon, 06 Jun 2011 15:43:38 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Mon, 6 Jun 2011 15:41:27 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 23:41:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2011 23:41:18 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: AcwkenWKwUE/GQIPSxivLneH24aE6QAHRaZA References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> From: Vinod Joseph To: Ilya Varlashkin X-OriginalArrivalTime: 06 Jun 2011 22:41:25.0428 (UTC) FILETIME=[DDF4E740:01CC249A] Cc: idr@ietf.org, Amit Khopkar , Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 22:43:41 -0000 Ilya, Lets get this into perspective in regard to the NH draft: 1. New Capability is needed on all BGP speakers and the RR. Our proposal = uses existing BGP machinery and does not need new capabilities or SPF = instances created on the RR. 2. The NH draft presents a single (best based on metric) path to each = BGP speaker. There is currently no mechanism to present different paths = to two set of BGP speakers within the same POP - since the metric = presented to a given RR will influence that RR to always choose a single = best ASBR and announce that to the PE. Even if two RRs are used, and if = a BGP speakers manipulates the metric to prefer an ASBR closer to the = second RR - There is no guarantee that the needed ASBR path would be = presented ever. Our proposed solution facilities this easily, but just = indicating needed RTs that pertain to a given ASBR(s). 3. The NH draft has a problem when hierarchical RRs are used as Robert = pointed out. There are no issues with the presented approach. 4. RT constrain ensures that only routes that an RR is interested in is = propagated between RRs. This is not possible with the NH draft. 5. Manipulation of metrics using administrative values result in = multiple touch-points anyways. The proposed approach is a replica of the = VPNv4 model which uses RTs and RT constrain. I am not sure why this is = considered operationally complex to configure? As far as grouping of = ASBRs and RT goes: There are multiple approaches (1) Group all ASBRs = within a region/POP to use a single RT (2) Group ASBRs in terms of = function (peering vs transit) wit similar RTs (3) If the dynamics change = where a certain set of BGP speakers need additional information from an = ASBR with a different RT - The ASBR needs to just announce its prefixes = with an additional RT - Single change. 6. There is strong interest in having a flexible approach wherein a = single network can have the flexibility that RT and RT constrain can = offer, with a mix of restricting paths advertised per RT, Have = resiliency by using a set of RTs signalled by BGP speakers in addition = to an RT which is uniquely identified per RR - to have best paths only = for all other prefixes. Note that carriers want to have the flexibility = of pre-defined primary, backup, paths that may not necessarily be the = shortest IGP path at all instances. This draft provides that.=20 7. Providers needs to deploy services (for eg, DNS, RADIUS, etc) with = geo-resiliecy with a view of offering high avalability, geo resiliency = and load sharing to scale the solution horizontally. In such requirments = anycast routing approach may seem to be favourable. A virtual address or = set of addresses for each application may be advertised via BGP from = every service PoP The advantage of using BGP is that PE routers could = learn BGP paths to each service PoP and have a local policy based on = affinity or other design to load-share and provide resilience. However the downside of this approach is that all PE routers are = required to have a mesh of BGP sessions to all service PoPs in addition = to the exsiting iBGP sessions with RR's and other eBGP sessions. PEs at = service PoP also need to support a large number of BGP sessions (linear = to the number of PEs in the network under consideration). Operationally it implies that any PoP commissiong or de-commissiong = activty involves multiple touch points on the network and additional = change control processes need to be invoked as business critical = services are located beind PE in service POPs. This also increases the = risk to other services by nature of change enforced at multiple points In the case of this solution, Multiple paths can be presented and = effectively used in these solutions as the RR completely decouples = itself from the path selection process and PE routers are presented with = all available paths to service POPs. No additional BGP sessions are = needed other than the existing iBGP sessions with RRs.=20 Providers also benefit from the fact this is a very light touch approach = and service PoPs can be gracefully taken offline for maintenance by = easily singalling a community or other attribute over a iBGP session to = the RRs by a service PE, as an example (the same can be achieved today = but the service PE needs to signal this to all the PEs in the network = and also implies that coherent BGP polices have been implement for each = iBGP neighbour) OR The entire PoP can be brought off-line by = manupulating IGP metrics which may always not be possible if multiple = services/applications are offered from this PoP.=20 More importantly it allows service provides to operate services in a = very low touch mode where chances of collateral damage are minimised, = policy enforcement is made simpler and is also easy on operational = processes & resources. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Ilya Varlashkin [mailto:ilya@nobulus.com]=20 Sent: 06 June 2011 19:49 To: Vinod Joseph Cc: idr@ietf.org Subject: Re: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) On Jun 6, 2011, at 20:21 , Vinod Joseph wrote: > Depending on the scale and capability of the PE, only a given number = of ASBR paths can be indicated as acceptable. For instance a PE may = indicate a preference of only 3 paths per RT. Whenever a path is = withdrawn, the RR would announce an additional path (if available within = the context of the RT signalled) to the PE.=20 >=20 Let's get specific. Consider 10 ASBR's in Europe and 10 in USA, and a = bunch of PE's in each of these regions. Closest (according to current = active) topology exit to reach foreign network is required. How many = RT's do we need to cover this case, how many PATHs should RR advertise = to PE, and what happens when this RR goes away? next round: what will be = behaviour when a prefix learned via an ASBR that does not advertise RT = in which PE is interested? Kind regards, iLya From raszuk@cisco.com Mon Jun 6 16:26:35 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9595A1F0C4E for ; Mon, 6 Jun 2011 16:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.165 X-Spam-Level: X-Spam-Status: No, score=-9.165 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-pXox88JcMt for ; Mon, 6 Jun 2011 16:26:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8EA1F0C44 for ; Mon, 6 Jun 2011 16:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=8820; q=dns/txt; s=iport; t=1307402794; x=1308612394; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=WNBrgcYHDIPx5wUgsvOtJhVicmD9tRScqyklyMo5jxM=; b=RiOnsXxONL5t+gu7Mj65O+LrryXbKFIYO3JBQukMb7oe1eodB2JnU90M w4yBE+7bldHPOicElQ7O88KzLilsKZ6fIXs9dFZBkHSiqdXE6jun7mXVS sEqiMIi87Mk+tw8zdFb7kKrWiXLf8VndikYVq0ku6LAvyDwdOpkH7I+uP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAO9h7U2rRDoH/2dsb2JhbABTphd3iHGjRIJ8DwGbCYYhBJEDhEyKeA X-IronPort-AV: E=Sophos;i="4.65,328,1304294400"; d="scan'208";a="460740774" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 06 Jun 2011 23:26:33 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p56NQWFM002536 for ; Mon, 6 Jun 2011 23:26:33 GMT Message-ID: <4DED6239.3030403@cisco.com> Date: Tue, 07 Jun 2011 01:26:49 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:26:35 -0000 Vinod, Lets get this into perspective in regard to your draft too ... > 1. New Capability is needed on all BGP speakers and the RR. Our > proposal uses existing BGP machinery and does not need new > capabilities or SPF instances created on the RR. I would like to observe that I am not aware of any network wide deployment of RT-Constrain today in the world - even for L3VPNs where it fits nicely .. most PEs and RRs just do not support it. Yes you have it in your lab running junos, but this is one of N routing stacks deployed today. > 2. The NH draft presents a single (best based on metric) path to each > BGP speaker. There is currently no mechanism to present different > paths to two set of BGP speakers within the same POP - since the > metric presented to a given RR will influence that RR to always > choose a single best ASBR and announce that to the PE. Even if two > RRs are used, and if a BGP speakers manipulates the metric to prefer > an ASBR closer to the second RR - There is no guarantee that the > needed ASBR path would be presented ever. Our proposed solution > facilities this easily, but just indicating needed RTs that pertain > to a given ASBR(s). I think this clearly demonstrates that you lack understanding of what NH draft defines and therefor I would encourage you to read it again .. and again .. till you manage to understand it's technical value. In the event this will be hard please do consult your company's colleagues which do understand NH-SAFI draft very well. > 3. The NH draft has a problem when hierarchical RRs are used as > Robert pointed out. There are no issues with the presented approach. Excuse me ? Please first refrain if you could from putting such false statement in the WG emails. I do not recall I ever said NH draft has issues with hierarchical RRs. If you would actually read my draft you would clearly see the below two paragraphs: sec 3 In the network architectures consisting of more then single pair of route reflectors it is required that all reflectors are fully meshed and have ability to learn and maintain all external BGP paths. In the event of constructing a hierarchy of reflectors to relax the full RR mesh requirements ORR should not be run between such route reflectors. + sec 4.3 Deploy add-paths between route reflectors in order to maximize path diversity within the cluster. That explains very clearly that top level RR in the hierarchical setups does not provide any ORR and by using add-paths encoding distributes all paths to the lower level of RRs. > 4. RT constrain ensures that only routes that an RR is interested in > is propagated between RRs. This is not possible with the NH draft. Great .. so now we are talking about even bigger outage then I originally assumed by PE-RR RT signaling. Those paths are not on RR as RR did not asked corresponding ASBR to send towards it the available unicast paths. What a broken and completely no resiliency based design. In the interest of IDR members and my own time I will refrain from even commenting any more on the below points. I encourage you to pursue your ideas and your draft further as long as you rename the draft. It is just not ethical to call it the same name as existing WG document which actually works and addresses real large operator's needs. Regards, R. PS. The further your draft goes the better .... ;-) if you know what I mean. > 5. Manipulation of metrics using administrative values result in > multiple touch-points anyways. The proposed approach is a replica of > the VPNv4 model which uses RTs and RT constrain. I am not sure why > this is considered operationally complex to configure? As far as > grouping of ASBRs and RT goes: There are multiple approaches (1) > Group all ASBRs within a region/POP to use a single RT (2) Group > ASBRs in terms of function (peering vs transit) wit similar RTs (3) > If the dynamics change where a certain set of BGP speakers need > additional information from an ASBR with a different RT - The ASBR > needs to just announce its prefixes with an additional RT - Single > change. > > 6. There is strong interest in having a flexible approach wherein a > single network can have the flexibility that RT and RT constrain can > offer, with a mix of restricting paths advertised per RT, Have > resiliency by using a set of RTs signalled by BGP speakers in > addition to an RT which is uniquely identified per RR - to have best > paths only for all other prefixes. Note that carriers want to have > the flexibility of pre-defined primary, backup, paths that may not > necessarily be the shortest IGP path at all instances. This draft > provides that. > > 7. Providers needs to deploy services (for eg, DNS, RADIUS, etc) with > geo-resiliecy with a view of offering high avalability, geo > resiliency and load sharing to scale the solution horizontally. In > such requirments anycast routing approach may seem to be favourable. > A virtual address or set of addresses for each application may be > advertised via BGP from every service PoP The advantage of using BGP > is that PE routers could learn BGP paths to each service PoP and have > a local policy based on affinity or other design to load-share and > provide resilience. > > However the downside of this approach is that all PE routers are > required to have a mesh of BGP sessions to all service PoPs in > addition to the exsiting iBGP sessions with RR's and other eBGP > sessions. PEs at service PoP also need to support a large number of > BGP sessions (linear to the number of PEs in the network under > consideration). > > Operationally it implies that any PoP commissiong or de-commissiong > activty involves multiple touch points on the network and additional > change control processes need to be invoked as business critical > services are located beind PE in service POPs. This also increases > the risk to other services by nature of change enforced at multiple > points > > In the case of this solution, Multiple paths can be presented and > effectively used in these solutions as the RR completely decouples > itself from the path selection process and PE routers are presented > with all available paths to service POPs. No additional BGP sessions > are needed other than the existing iBGP sessions with RRs. > > Providers also benefit from the fact this is a very light touch > approach and service PoPs can be gracefully taken offline for > maintenance by easily singalling a community or other attribute over > a iBGP session to the RRs by a service PE, as an example (the same > can be achieved today but the service PE needs to signal this to all > the PEs in the network and also implies that coherent BGP polices > have been implement for each iBGP neighbour) OR The entire PoP can be > brought off-line by manupulating IGP metrics which may always not be > possible if multiple services/applications are offered from this > PoP. > > More importantly it allows service provides to operate services in a > very low touch mode where chances of collateral damage are minimised, > policy enforcement is made simpler and is also easy on operational > processes& resources. > > Regards > > Vinod Joseph Professional Services - Service Provider Europe Juniper > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net > > > > > -----Original Message----- From: Ilya Varlashkin > [mailto:ilya@nobulus.com] Sent: 06 June 2011 19:49 To: Vinod Joseph > Cc: idr@ietf.org Subject: Re: [Idr] more on > draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, > Vol 86, Issue 5) > > On Jun 6, 2011, at 20:21 , Vinod Joseph wrote: > >> Depending on the scale and capability of the PE, only a given >> number of ASBR paths can be indicated as acceptable. For instance a >> PE may indicate a preference of only 3 paths per RT. Whenever a >> path is withdrawn, the RR would announce an additional path (if >> available within the context of the RT signalled) to the PE. >> > > Let's get specific. Consider 10 ASBR's in Europe and 10 in USA, and a > bunch of PE's in each of these regions. Closest (according to current > active) topology exit to reach foreign network is required. How many > RT's do we need to cover this case, how many PATHs should RR > advertise to PE, and what happens when this RR goes away? next round: > what will be behaviour when a prefix learned via an ASBR that does > not advertise RT in which PE is interested? > > Kind regards, iLya > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > From ilya@nobulus.com Tue Jun 7 01:31:34 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0D121F84B3 for ; Tue, 7 Jun 2011 01:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiCCjMcxudGj for ; Tue, 7 Jun 2011 01:31:34 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 85B5321F84BE for ; Tue, 7 Jun 2011 01:31:32 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 4B7021744F; Tue, 7 Jun 2011 10:31:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yueZwgHN66C7; Tue, 7 Jun 2011 10:31:27 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:1198:1073:b5b7:33f9]) by nobulus.com (Postfix) with ESMTPA id 8B42B1711F; Tue, 7 Jun 2011 10:31:25 +0200 (CEST) Message-ID: <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> From: "iLya" To: "Vinod Joseph" References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> Date: Tue, 7 Jun 2011 10:31:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org, Amit Khopkar , Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 08:31:35 -0000 Hi Vinod, -------------------------------------------------- > 1. New Capability is needed on all BGP speakers and the RR. Our proposal > uses existing BGP machinery and does not need new capabilities or SPF > instances created on the RR. > NH draft indeed requires new capability, but solves the problem, WG ORR draft does not require new capability and solves the problem. Your draft doesn't require new capability but doesn't solve problem either. > 2. The NH draft presents a single (best based on metric) path to each BGP > speaker. There is currently no mechanism to NH draft only provides source of information to RR, but does not specify whether single or multiple paths are sent by RR to PE, the routers are free to use any current or future techniques to exchange single or multiple PATH's. > 3. The NH draft has a problem when hierarchical RRs are used as Robert > pointed out. There are no issues with the presented approach. > I have pointed out during my presentation in Prague that if inter-RR optimisation is required, then it can be addressed. If there is no practical interest, then there's no point in wasting effort solving academic problem outside of academic realm. > 4. RT constrain ensures that only routes that an RR is interested in is > propagated between RRs. This is not possible with the NH draft. RT constrain also ensures that if routes are not marked with certain community, then PE checking that community will never receive the routes and will either not be able to access the network in question or will reach it through sub-optimum path (e.g. via default). > > 5. Manipulation of metrics using administrative values result in multiple > touch-points anyways. The proposed approach is a replica of the VPNv4 > model which uses RTs and RT constrain. I am not sure why this is > considered operationally complex to configure? As far as grouping of ASBRs > and RT goes: There are multiple approaches (1) Group all ASBRs within a > region/POP I propose you book a month in NOC as your next holiday destination. Anything that needs to be configured by human is error prone. Anything that you propose to configure by a script is just a shift of responsibility - as network operator I'd like to see vendors delivering solutions and not saying "hey, but you could just solve it yourself". At VPNv4/v6 we know in advance all potential routers where a prefix can be learned so we can ensure that they're marked with appropriate RT. For global Internet routes we don't have this information and therefore cannot mark them appropriately. > to use a single RT (2) Group ASBRs in terms of function (peering vs > transit) wit similar RTs it's not unusual to have transit and peering on the same devices. And peer vs. transit can easily be addressed with long-existing tools as local-pref, MED and custom decision process metric, no need for any new mechanism. > (3) If the dynamics change where a certain set of BGP speakers need > additional information from an ASBR with a different RT - The ASBR needs > to just announce its prefixes with an additional RT - Single change. yes, single change every time a prefix is announced differently. And we will introduce new position at NOCs - real-time routing table observer; skills required - lightningfast analysis of 400K routes and outstanding typing speed. > 6. There is strong interest in having a flexible approach wherein a single > network can have the flexibility that RT and RT constrain can offer, with > a mix of restricting paths advertised per RT, Have resiliency by using a > set of RTs signalled by BGP speakers in addition to an RT which is > uniquely identified per RR - to have best paths only for all other > prefixes. Note that carriers want to have the flexibility of pre-defined > primary, backup, paths that may not necessarily be the shortest IGP path > at all instances. This draft provides that. > sorry but your draft does not guarentee that a router will be able to obtain full routing table. We need full routing table to access the Internet. > 7. Providers needs to deploy services (for eg, DNS, RADIUS, etc) with > geo-resiliecy with a view of offering high [...] > In the case of this solution, Multiple paths can be presented and > effectively used in these solutions as the RR which is nothing new - has been like this since ADD-PATH. And IDR WG ORR draft allows sending best and next-best on per-PE basis without requiring any changes in the PE (beyond supporting ADD-PATH). To restate it once more - your draft has problem with guaranteeing delivery of all routes to a PE. Until you address that issue, it doesn't matter what else you're trying to solve. Kind regards, iLya From vjoseph@juniper.net Tue Jun 7 01:42:14 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42DB21F8554 for ; Tue, 7 Jun 2011 01:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QapcIXQMNK4h for ; Tue, 7 Jun 2011 01:42:14 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id D9E9A21F854E for ; Tue, 7 Jun 2011 01:42:08 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTe3kXDaa31kkUAukZf7aKMtIurnzJwdE@postini.com; Tue, 07 Jun 2011 01:42:13 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Tue, 7 Jun 2011 01:41:41 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 09:41:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 09:41:03 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk7VDj1XHubdjqQm+2Xfq7Vj/XawAAFcBA References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> From: Vinod Joseph To: iLya X-OriginalArrivalTime: 07 Jun 2011 08:41:40.0536 (UTC) FILETIME=[B8A24380:01CC24EE] Cc: idr@ietf.org, Amit Khopkar , Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 08:42:15 -0000 sorry but your draft does not guarentee that a router will be able to = obtain full routing table. We need full routing table to access the = Internet. Vinod# I presume you have read the RT constrain draft. Full Internet = routes can be received by using the Default RT which is equal to = prefixes with all Route Targets. The point here is not about whether this draft is superior to superior = to the NH draft, its very clear that this proposal offers the = flexibility that is not addressed by your draft. Can you answer this: This draft proposes a scheme where each PE in a POP may use a separate = ASBR for exit, by means of announcing interest in specific Route = Targets. In other words an operator can use certain ASBRs for certain = PEs that are within the same POP, as primary exit points. Even if you = would cost an ASBR administratively, can you elaborate how would = influence one PE within the same POP as the ASBR to choose the local = ASBR and another PE to use an ASBR in a remote POP? Since the RR is = doing the best path calculation in your case? Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: iLya [mailto:ilya@nobulus.com]=20 Sent: 07 June 2011 09:31 To: Vinod Joseph Cc: idr@ietf.org; Amit Khopkar; Laurent Lavallee Subject: Re: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) Hi Vinod, -------------------------------------------------- > 1. New Capability is needed on all BGP speakers and the RR. Our = proposal=20 > uses existing BGP machinery and does not need new capabilities or SPF=20 > instances created on the RR. > NH draft indeed requires new capability, but solves the problem, WG ORR=20 draft does not require new capability and solves the problem. Your draft = doesn't require new capability but doesn't solve problem either. > 2. The NH draft presents a single (best based on metric) path to each = BGP=20 > speaker. There is currently no mechanism to NH draft only provides source of information to RR, but does not specify = whether single or multiple paths are sent by RR to PE, the routers are = free=20 to use any current or future techniques to exchange single or multiple=20 PATH's. > 3. The NH draft has a problem when hierarchical RRs are used as Robert = > pointed out. There are no issues with the presented approach. > I have pointed out during my presentation in Prague that if inter-RR=20 optimisation is required, then it can be addressed. If there is no = practical=20 interest, then there's no point in wasting effort solving academic = problem=20 outside of academic realm. > 4. RT constrain ensures that only routes that an RR is interested in = is=20 > propagated between RRs. This is not possible with the NH draft. RT constrain also ensures that if routes are not marked with certain=20 community, then PE checking that community will never receive the routes = and=20 will either not be able to access the network in question or will reach = it=20 through sub-optimum path (e.g. via default). > > 5. Manipulation of metrics using administrative values result in = multiple=20 > touch-points anyways. The proposed approach is a replica of the VPNv4=20 > model which uses RTs and RT constrain. I am not sure why this is=20 > considered operationally complex to configure? As far as grouping of = ASBRs=20 > and RT goes: There are multiple approaches (1) Group all ASBRs within = a=20 > region/POP I propose you book a month in NOC as your next holiday destination. = Anything=20 that needs to be configured by human is error prone. Anything that you=20 propose to configure by a script is just a shift of responsibility - as=20 network operator I'd like to see vendors delivering solutions and not = saying=20 "hey, but you could just solve it yourself". At VPNv4/v6 we know in = advance=20 all potential routers where a prefix can be learned so we can ensure = that=20 they're marked with appropriate RT. For global Internet routes we don't = have=20 this information and therefore cannot mark them appropriately. > to use a single RT (2) Group ASBRs in terms of function (peering vs=20 > transit) wit similar RTs it's not unusual to have transit and peering on the same devices. And = peer=20 vs. transit can easily be addressed with long-existing tools as = local-pref,=20 MED and custom decision process metric, no need for any new mechanism. > (3) If the dynamics change where a certain set of BGP speakers need=20 > additional information from an ASBR with a different RT - The ASBR = needs=20 > to just announce its prefixes with an additional RT - Single change. yes, single change every time a prefix is announced differently. And we = will=20 introduce new position at NOCs - real-time routing table observer; = skills=20 required - lightningfast analysis of 400K routes and outstanding typing=20 speed. > 6. There is strong interest in having a flexible approach wherein a = single=20 > network can have the flexibility that RT and RT constrain can offer, = with=20 > a mix of restricting paths advertised per RT, Have resiliency by using = a=20 > set of RTs signalled by BGP speakers in addition to an RT which is=20 > uniquely identified per RR - to have best paths only for all other=20 > prefixes. Note that carriers want to have the flexibility of = pre-defined=20 > primary, backup, paths that may not necessarily be the shortest IGP = path=20 > at all instances. This draft provides that. > sorry but your draft does not guarentee that a router will be able to = obtain=20 full routing table. We need full routing table to access the Internet. > 7. Providers needs to deploy services (for eg, DNS, RADIUS, etc) with=20 > geo-resiliecy with a view of offering high [...] > In the case of this solution, Multiple paths can be presented and=20 > effectively used in these solutions as the RR which is nothing new - has been like this since ADD-PATH. And IDR WG ORR = draft allows sending best and next-best on per-PE basis without = requiring=20 any changes in the PE (beyond supporting ADD-PATH). To restate it once more - your draft has problem with guaranteeing = delivery=20 of all routes to a PE. Until you address that issue, it doesn't matter = what=20 else you're trying to solve. Kind regards, iLya =20 From raszuk@cisco.com Tue Jun 7 02:12:59 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD8121F8602 for ; Tue, 7 Jun 2011 02:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1SqyaOiK-Pj for ; Tue, 7 Jun 2011 02:12:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBA421F84B1 for ; Tue, 7 Jun 2011 02:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1887; q=dns/txt; s=iport; t=1307437978; x=1308647578; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=O+gRY3VoWMETm+xkpTwDR4H7nukIvujo24Q9tepStYM=; b=EdmgobSbSg0LZXzBC0J/COJrbxPDzP+eAUjODwxKFme502rFsU+sc5lm UgvBjeeqEBvhPAcSBBSasMEDBaYaeHLylSCEmmpJZsuThu7HDrtZqghph L+MGMVOAxURG80j0vfjI+JO5qFr2QYO/R9Gc6DWZIz7sDOnCU1U/z/Mgv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEGAAXr7U2rRDoJ/2dsb2JhbABTl3COKHeIcaJxgn4PAZsahiEEkQqETIp7 X-IronPort-AV: E=Sophos;i="4.65,331,1304294400"; d="scan'208";a="331673264" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2011 09:12:58 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p579CvKb005618 for ; Tue, 7 Jun 2011 09:12:57 GMT Message-ID: <4DEDEBAA.3090305@cisco.com> Date: Tue, 07 Jun 2011 11:13:14 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 09:12:59 -0000 Vinod, The most interesting point within your serious of replies is that you do not even understand what you are missing. > Vinod# I presume you have read the RT constrain draft. Full Internet > routes can be received by using the Default RT which is equal to > prefixes with all Route Targets. So you write a draft, recommend to use RT constrain in it to filter preferred paths then on top of all of that call for using the default route target to get all paths in order to make sure RR client can still reach destinations in the event of some paths being withdrawn. What a total nonsense. R. > sorry but your draft does not guarentee that a router will be able to > obtain full routing table. We need full routing table to access the > Internet. > > Vinod# I presume you have read the RT constrain draft. Full Internet > routes can be received by using the Default RT which is equal to > prefixes with all Route Targets. > > The point here is not about whether this draft is superior to > superior to the NH draft, its very clear that this proposal offers > the flexibility that is not addressed by your draft. > > Can you answer this: > > This draft proposes a scheme where each PE in a POP may use a > separate ASBR for exit, by means of announcing interest in specific > Route Targets. In other words an operator can use certain ASBRs for > certain PEs that are within the same POP, as primary exit points. > Even if you would cost an ASBR administratively, can you elaborate > how would influence one PE within the same POP as the ASBR to choose > the local ASBR and another PE to use an ASBR in a remote POP? Since > the RR is doing the best path calculation in your case? > > Regards > > Vinod Joseph Professional Services - Service Provider Europe Juniper > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net From raszuk@cisco.com Tue Jun 7 02:21:02 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF63711E8081 for ; Tue, 7 Jun 2011 02:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.287 X-Spam-Level: X-Spam-Status: No, score=-10.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pysz6D8aunls for ; Tue, 7 Jun 2011 02:21:02 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 03D0C11E8077 for ; Tue, 7 Jun 2011 02:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1364; q=dns/txt; s=iport; t=1307438461; x=1308648061; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=U3sO2YIbgjzO8RK0xEI1UYbTDVs1MtpZt9izzXcY4HA=; b=M254fGN4/kjSQSBLw/rW4WqH4ueDZ3pfepYulGSWnvZtXRT44h8sfy0h KgilHk3wYLlstaKINU5tMUM9yep+00ab4cCCkG4QwIAlzMPVdLRuBA5jc 6xiWChRl7WvWoA61zk2gtco7q3CiaKSNNlOK9b+U1XfZQVamg0kjdXIqJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEGADHs7U2rRDoI/2dsb2JhbABTl3COKHeIcaJwgn4PAZsahiEEkQqETIp7 X-IronPort-AV: E=Sophos;i="4.65,331,1304294400"; d="scan'208";a="331677190" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2011 09:20:31 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p579KU7r006390 for ; Tue, 7 Jun 2011 09:20:31 GMT Message-ID: <4DEDED70.4010502@cisco.com> Date: Tue, 07 Jun 2011 11:20:48 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 09:21:02 -0000 Vinod, > Can you answer this: Of course. > This draft proposes a scheme where each PE in a POP may use a > separate ASBR for exit, by means of announcing interest in specific > Route Targets. In other words an operator can use certain ASBRs for > certain PEs that are within the same POP, as primary exit points. > Even if you would cost an ASBR administratively, can you elaborate > how would influence one PE within the same POP as the ASBR to choose > the local ASBR and another PE to use an ASBR in a remote POP? Since > the RR is doing the best path calculation in your case? Trivial case. RR sends NH-SAFI request to PE1 and PE2 listing two next hops nh1 and nh2 corresponding to paths received via local ASBR1 in the POP and some remote ASBR2 in the other POP. PE1 replies to RR: nh1 metric 100 nh2 metric 200 PE2 replies to RR: nh1 metric 200 nh2 metric 100 Done ! RR will consider optimal path for PE1 from ASBR1 (lowest metric) and for PE2 the optimal path will be the one advertised by ASBR2 (lowest metric). No need to worry about any manual re-assignment of anything during any network failure or path withdraw. RR will always send another path and PEs would not need to keep more paths then they need to use at any point of time. Case solved. Thx, R. From ilya@nobulus.com Tue Jun 7 02:28:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED1D11E80B9 for ; Tue, 7 Jun 2011 02:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyJuhYAT0VGo for ; Tue, 7 Jun 2011 02:28:05 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 52AF611E80AD for ; Tue, 7 Jun 2011 02:28:04 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 5EC1F1711F; Tue, 7 Jun 2011 11:28:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cg-40ODJuGBM; Tue, 7 Jun 2011 11:28:00 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:1198:1073:b5b7:33f9]) by nobulus.com (Postfix) with ESMTPA id 1F293170CD; Tue, 7 Jun 2011 11:27:58 +0200 (CEST) Message-ID: <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> From: "iLya" To: "Vinod Joseph" References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> Date: Tue, 7 Jun 2011 11:27:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org, Amit Khopkar , Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 09:28:06 -0000 -------------------------------------------------- > Can you answer this: > > This draft proposes a scheme where each PE in a POP may use a separate > ASBR for exit, by means of announcing interest in specific Route Targets. > In other words an operator can use certain ASBRs for certain PEs that are > within the same POP, as primary exit points. Even if you would cost an > ASBR administratively, can you elaborate how would influence one PE within > the same POP as the ASBR to choose the local ASBR and another PE to use an > ASBR in a remote POP? Since the RR is doing the best path calculation in > your case? > In case of NH SAFI each PE may just announces administrative cost to next-hops, e.g. (in their announces to RR) PE1 announces cost 10 to NH1 and 15 to NH2, while PE2 announces cost 20 to NH2 and cost 40 to NH1, the rest is assured by section 3 of NH SAFI draft. RR then uses this cost instead of its own when performing per-client (or per-group) best path selection, so if a prefix A is reachable via both NH1 and NH2, then PE1 will receive "A-via-NH1" as best (and optionally "-via-NH2" as next-best) and PE2 will receive "A-via-NH2" as best (and optionally "-via-NH1" as next-best). Cheers, iLya From vjoseph@juniper.net Tue Jun 7 02:37:30 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE8D21F84A1 for ; Tue, 7 Jun 2011 02:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbDjWvFKCUw0 for ; Tue, 7 Jun 2011 02:37:30 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDF521F8496 for ; Tue, 7 Jun 2011 02:37:25 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTe3xVDzJ8arZueToqlH8kcOjRp0oIV8o@postini.com; Tue, 07 Jun 2011 02:37:29 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Tue, 7 Jun 2011 02:36:14 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 10:36:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 10:36:07 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk9TdMwUDksX1CQ6ieUFIrfuWhBQAAHw9w References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> From: Vinod Joseph To: iLya X-OriginalArrivalTime: 07 Jun 2011 09:36:12.0752 (UTC) FILETIME=[5706CD00:01CC24F6] Cc: idr@ietf.org, Amit Khopkar , Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 09:37:31 -0000 Interesting enough. I just needed this to be spelt out. So there is enough overhead here is calculating and assigning = administrative costs between each PE-ASBR pair, if traffic flows need to = be addressed in this manner. I would imagine how easy it would be to do = this on a larger scale if there are diverse requirements as such.=20 Add IPv6 to this, and you have another set of administrative costs + = calculations to be made. Makes it more interesting.=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: iLya [mailto:ilya@nobulus.com]=20 Sent: 07 June 2011 10:28 To: Vinod Joseph Cc: idr@ietf.org; Amit Khopkar; Laurent Lavallee Subject: Re: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) -------------------------------------------------- > Can you answer this: > > This draft proposes a scheme where each PE in a POP may use a separate = > ASBR for exit, by means of announcing interest in specific Route = Targets.=20 > In other words an operator can use certain ASBRs for certain PEs that = are=20 > within the same POP, as primary exit points. Even if you would cost an = > ASBR administratively, can you elaborate how would influence one PE = within=20 > the same POP as the ASBR to choose the local ASBR and another PE to = use an=20 > ASBR in a remote POP? Since the RR is doing the best path calculation = in=20 > your case? > In case of NH SAFI each PE may just announces administrative cost to=20 next-hops, e.g. (in their announces to RR) PE1 announces cost 10 to NH1 = and=20 15 to NH2, while PE2 announces cost 20 to NH2 and cost 40 to NH1, the = rest=20 is assured by section 3 of NH SAFI draft. RR then uses this cost instead = of=20 its own when performing per-client (or per-group) best path selection, = so if=20 a prefix A is reachable via both NH1 and NH2, then PE1 will receive=20 "A-via-NH1" as best (and optionally "-via-NH2" as next-best) and PE2 = will=20 receive "A-via-NH2" as best (and optionally "-via-NH1" as next-best). Cheers, iLya =20 From ilya@nobulus.com Tue Jun 7 02:46:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A3C21F8542 for ; Tue, 7 Jun 2011 02:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, MANGLED_NAIL=2.3, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO-OMkXa1p2t for ; Tue, 7 Jun 2011 02:45:59 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id CFEA921F8541 for ; Tue, 7 Jun 2011 02:45:58 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id B29D4170F0; Tue, 7 Jun 2011 11:45:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id u+9GcF2VmU4u; Tue, 7 Jun 2011 11:45:54 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:1198:1073:b5b7:33f9]) by nobulus.com (Postfix) with ESMTPA id D9EC5170CD; Tue, 7 Jun 2011 11:45:54 +0200 (CEST) Message-ID: <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> From: "iLya" To: "Vinod Joseph" References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> Date: Tue, 7 Jun 2011 11:45:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org, Amit Khopkar , Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 09:46:00 -0000 -------------------------------------------------- > Interesting enough. I just needed this to be spelt out. > > So there is enough overhead here is calculating and assigning > administrative costs between each PE-ASBR pair, if traffic flows need to > be addressed in this manner. I would imagine how easy it would be to do > this on a larger scale if there are diverse requirements as such. > we've been through this about a month ago - discussing overheads and costs and scaleability of ORR on IDR mailing list. If you have some new info to add, please bring it up, otherwise it appeared we have addressed the issue positively (see archives). > Add IPv6 to this, and you have another set of administrative costs + > calculations to be made. Makes it more interesting. > if you prefer different exit for v6 than for v4, then yes - more costs, otherwise you just use option "admin cost N all-afi" and done. As for number of calculations - the amount of work is constant, whether it's cheaper/more efficient to perform this on RR or on PE is discussed earlier as mentioned above. Cheers, iLya From ilya@nobulus.com Tue Jun 7 03:38:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4622711E80F0 for ; Tue, 7 Jun 2011 03:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li1k+oar3WS8 for ; Tue, 7 Jun 2011 03:38:21 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 2C05811E80CA for ; Tue, 7 Jun 2011 03:38:21 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 4AA7817391; Tue, 7 Jun 2011 12:38:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 88oT37p66MIs; Tue, 7 Jun 2011 12:38:16 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:1198:1073:b5b7:33f9]) by nobulus.com (Postfix) with ESMTPA id 91D5F1732F; Tue, 7 Jun 2011 12:38:16 +0200 (CEST) Message-ID: <8E71198A8DF74C62B6C2C810B0CA5061@hnivarlas1> From: "iLya" To: "Amit Khopkar" , "Vinod Joseph" References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> In-Reply-To: Date: Tue, 7 Jun 2011 12:38:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org, Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:38:22 -0000 -------------------------------------------------- > As a network operator we believe the approach using RTs is simpler than > adding more computation and software complexity on the RR which is not > free of scalability concerns. > Amit, I am truely surprised that you as network operator don't see that RT-based proposal in its current form cannot provide full routing table. Kind regards, iLya From ilya@nobulus.com Tue Jun 7 04:11:15 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB98921F8572 for ; Tue, 7 Jun 2011 04:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIxpd+42CZUD for ; Tue, 7 Jun 2011 04:11:15 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD6321F856E for ; Tue, 7 Jun 2011 04:11:14 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 40B121744E; Tue, 7 Jun 2011 13:11:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id w3-+AVJIgcbz; Tue, 7 Jun 2011 13:11:11 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:1198:1073:b5b7:33f9]) by nobulus.com (Postfix) with ESMTPA id 406BB1743C; Tue, 7 Jun 2011 13:11:11 +0200 (CEST) Message-ID: <9740E67C369F49A3BD1CC4FA9C27E403@hnivarlas1> From: "iLya" To: "Amit Khopkar" , "Vinod Joseph" References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <8E71198A8DF74C62B6C2C810B0CA5061@hnivarlas1> In-Reply-To: Date: Tue, 7 Jun 2011 13:11:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 11:11:15 -0000 -------------------------------------------------- > I think Vinod has covered some options to support this requirement in an > earlier email. > Must have been written in invisible ink. Unless you referring to "use default RT", which degrades behaviour to ordinary ADD-PATH and hence does not bring anything that wasn't already there. I'm all ears and eyes to learn how exactly your draft proposes to address full routing table issue. Kind regards, iLya From vjoseph@juniper.net Tue Jun 7 04:20:28 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0F611E80C4 for ; Tue, 7 Jun 2011 04:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn-MHM8w0eev for ; Tue, 7 Jun 2011 04:20:28 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2475911E808F for ; Tue, 7 Jun 2011 04:20:23 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTe4JdvyrDDgODMy6XVFFucpm7CSHP7ow@postini.com; Tue, 07 Jun 2011 04:20:27 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Tue, 7 Jun 2011 04:19:51 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 12:19:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 12:19:46 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996E3D@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: AcwlA62tGcudPYJpSVeCGlw8CBXJBwAABJWQ References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <8E71198A8DF74C62B6C2C810B0CA5061@hnivarlas1> <9740E67C369F49A3BD1CC4FA9C27E403@hnivarlas1> From: Vinod Joseph To: iLya , Amit Khopkar X-OriginalArrivalTime: 07 Jun 2011 11:19:50.0111 (UTC) FILETIME=[D0DC7EF0:01CC2504] Cc: idr@ietf.org, Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 11:20:28 -0000 Ilya, 1. Use of an RR specific RT, which enables the RR to send only the best = path (RR calculated using the default behaviour) for all prefixes in = addition to RT specific prefixes that a BGP speaker would explicitedly = indicate interest in. 2. Section 5.8 of the draft: Use of the Default RT and also the ability = to indicate max no. of paths on a per RT basis. or even more max no. of = paths for all prefixes with RTs or without RTs. 3. Section 5:5 of the draft: Define a range of RTs. Let us consider a = scenario where, a BGP speaker is interested in multiple RTs. The = proposal suggests that any implementation should have the ability for a = given BGP speakers to use a range of RT values and Wildcards to signal = affinities. For example a range as follows indicates that the RT = Membership NLRI includes RT values of [1-20,30-35, 50]. This avoids the = need for configuring each RT value individually. RT constraint supports the notion of a RT-prefix. Hence all RTs can be = advertised as a single prefix assuming they are assigned from a prefix = (and that would be a reasonable deployment model). Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: iLya [mailto:ilya@nobulus.com]=20 Sent: 07 June 2011 12:11 To: Amit Khopkar; Vinod Joseph Cc: idr@ietf.org Subject: Re: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) -------------------------------------------------- > I think Vinod has covered some options to support this requirement in = an=20 > earlier email. > Must have been written in invisible ink. Unless you referring to "use=20 default RT", which degrades behaviour to ordinary ADD-PATH and hence = does=20 not bring anything that wasn't already there. I'm all ears and eyes to = learn=20 how exactly your draft proposes to address full routing table issue. Kind regards, iLya=20 From ilya@nobulus.com Tue Jun 7 07:27:44 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850B911E8130 for ; Tue, 7 Jun 2011 07:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T-WFNeyUOBi for ; Tue, 7 Jun 2011 07:27:44 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 492E311E812A for ; Tue, 7 Jun 2011 07:27:43 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 14E7E17478; Tue, 7 Jun 2011 16:27:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LPdyzybaX+7s; Tue, 7 Jun 2011 16:27:39 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:1198:1073:b5b7:33f9]) by nobulus.com (Postfix) with ESMTPA id 8FA6617391; Tue, 7 Jun 2011 16:27:37 +0200 (CEST) Message-ID: <25AE2BA0E71243BBABC422A40AB3AEED@hnivarlas1> From: "iLya" To: "Vinod Joseph" , "Amit Khopkar" References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <8E71198A8DF74C62B6C2C810B0CA5061@hnivarlas1> <9740E67C369F49A3BD1CC4FA9C27E403@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996E3D@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996E3D@emailemea4.jnpr.net> Date: Tue, 7 Jun 2011 16:27:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org, Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:27:44 -0000 -------------------------------------------------- From: "Vinod Joseph" Sent: Tuesday, June 07, 2011 1:19 PM To: "iLya" ; "Amit Khopkar" Cc: ; "Laurent Lavallee" Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) [skip] > 3. Section 5:5 of the draft: Define a range of RTs. Let us consider a > scenario where, a BGP speaker is interested in multiple RTs. The proposal > suggests that any implementation should have the ability for a given BGP > speakers to use a range of RT values and Wildcards to signal affinities. > For example a range as follows indicates that the RT Membership NLRI > includes RT values of [1-20,30-35, 50]. This avoids the need for > configuring each RT value > individually. > consider a network with presence in Europe (10 exits) and USA (10 exits). two route reflectors are deployed - one in UK and one south-west USA. A PE in Germany wants to use German exit points (but only if prefixes pass beyond MED consideration) as first choice and shortest IGP cost from their perspective otherwise. If the PE signals to RR that it wants prefixes with RT-Germany as first priority and rest IGP-cost-based, then for prefix A available over LINX and AMSIX and a private peer in France but not over DECIX the PE will get LINX prefixes, which are more far. Worst, when London's RR disappears (maintenance, failure) German PE will get US prefixes. Something does not compute. Kind regards, iLya From ilya@nobulus.com Tue Jun 7 07:40:42 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8236921F8455 for ; Tue, 7 Jun 2011 07:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oExa249cMxvg for ; Tue, 7 Jun 2011 07:40:42 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 46D3121F8451 for ; Tue, 7 Jun 2011 07:40:41 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id EFC3C1744F; Tue, 7 Jun 2011 16:40:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a5wIsIvLU8FG; Tue, 7 Jun 2011 16:40:37 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:1198:1073:b5b7:33f9]) by nobulus.com (Postfix) with ESMTPA id D43FD1743C; Tue, 7 Jun 2011 16:40:37 +0200 (CEST) Message-ID: From: "iLya" To: "Shah, Chintan" References: <5DD781A4BE13384A900438DF0608972C06996E1D@emailemea4.jnpr.net> <19040_1307448135_4DEE1346_19040_17758_1_0058F6DE932DAA41B10D5E668E09A64F22CE4626@ULVMCTMMAI002.INTERNAL.COLT.NET> In-Reply-To: <19040_1307448135_4DEE1346_19040_17758_1_0058F6DE932DAA41B10D5E668E09A64F22CE4626@ULVMCTMMAI002.INTERNAL.COLT.NET> Date: Tue, 7 Jun 2011 16:40:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org, Amit.Khopkar@sns.bskyb.com, vjoseph@juniper.net, "Thareja, Gaurav" Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:40:42 -0000 -------------------------------------------------- From: "Shah, Chintan" Sent: Tuesday, June 07, 2011 2:02 PM To: Cc: ; ; ; "Thareja, Gaurav" Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) > Hi ilya, > > To add to this, As a carrier we would not like to restrict the path > selection only based on IGP or an administrative cost. There are diverse > requirements and the RT approach eases our needs to define strict, and > flexible path selection criteria based on RT constrain. > please bring requirements forth and we'll see if they're not already addressed. I wonder why did you make secret of these requirements when before and after Prague we were discussing ORR. > Another advantage with the RT approach is: Carriers with service POP > deployments using Anycast can load balance traffic from end user to > multiple service POP through the use of RTs than just rely on IGP. There > is quite an amount of flexibility is there. > advantage compare to what, sorry? using NH SAFI a PE could simply signal equal cost to those "service PoPs" that it want to load-balance with, and if those PoP's are gone, next-best could take their place. if there is an advantage, then it's not of "possible/not possible" sort. > With respect to the discussion of configurations for new ASBR/PE, once > there is design in place for Operation with respect a carrier network, > there is always a need for standard operational practices needed for this, > and this is something carriers are used to - when it comes to the use of > RT (courtesy VPNv4 deployments) I see it as something simpler and more > flexible that considering it a burden. > let's be practical - what are conditions when desired exit point is not an IGP-closest? I can understand this as an expeption in few scenarios but why did all of a sudden world wants to route traffic elsewhere? Could it be that your IGP design is wrong? Kind regards, iLya From Amit.Khopkar@sns.bskyb.com Tue Jun 7 03:35:47 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B352E11E80CA for ; Tue, 7 Jun 2011 03:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MANGLED_NAIL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApatAThk4TyQ for ; Tue, 7 Jun 2011 03:35:47 -0700 (PDT) Received: from mailfilter0.bllon.isp.sky.com (mailfilter0.bllon.isp.sky.com [90.207.250.4]) by ietfa.amsl.com (Postfix) with ESMTP id E3F5011E8105 for ; Tue, 7 Jun 2011 03:35:46 -0700 (PDT) Received: from mailrouter0.bllon.isp.sky.com ([90.207.250.6]) by mailfilter0.bllon.isp.sky.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QTtd9-000595-Mq; Tue, 07 Jun 2011 11:35:42 +0100 Received: from 5acffa6b.bb.sky.com ([90.207.250.107] helo=exch2bl.sns.bskyb.corp) by mailrouter0.bllon.isp.sky.com with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1QTtd9-0003GN-BA; Tue, 07 Jun 2011 11:35:27 +0100 Received: from exch3cl.sns.bskyb.corp ([169.254.1.94]) by exch2bl.sns.bskyb.corp ([90.207.250.107]) with mapi; Tue, 7 Jun 2011 11:35:27 +0100 From: Amit Khopkar To: iLya , Vinod Joseph Date: Tue, 7 Jun 2011 11:35:26 +0100 Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk98CRaTVzPO6jRMKTThtq6pzlBQABmliQ Message-ID: References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> In-Reply-To: <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> 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-Mailfilter0-Spam-Score: -2.5 X-Mailman-Approved-At: Tue, 07 Jun 2011 07:48:24 -0700 Cc: "idr@ietf.org" , Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:35:47 -0000 Hi Ilya, lets take a step back from the details and revisit the current situation 1. In networks with BGP-free cores the route reflector ends up making a dec= ision on the best path from its point of view and filters other paths from = being advertised to the PE. 2. BGP ADD-PATH overcomes this challenge but has some scalability concerns 3. there are two approaches to resolve this a. let the route reflector make a decision for every PE based on so= me criteria (IGP metric in your draft) b. take the RR out of the route selection process (one of the main = reasons for existence of ADD-PATH) but in a scalable manner Also the question to ask is what is optimal? is it lowest IGP metric to nex= t hop or some other criteria that the operator wishes to exercise. there sh= ould be flexibility with the network operator to support this choice. As a network operator we believe the approach using RTs is simpler than add= ing more computation and software complexity on the RR which is not free of= scalability concerns. There are pros and cons to each approach and maybe there is space for both = approaches. let the market decide what it wants ;) cheers amit -----Original Message----- From: iLya [mailto:ilya@nobulus.com] Sent: 07 June 2011 10:46 To: Vinod Joseph Cc: idr@ietf.org; Amit Khopkar; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflectio= n (was: Idr Digest, Vol 86, Issue 5) -------------------------------------------------- > Interesting enough. I just needed this to be spelt out. > > So there is enough overhead here is calculating and assigning > administrative costs between each PE-ASBR pair, if traffic flows need to > be addressed in this manner. I would imagine how easy it would be to do > this on a larger scale if there are diverse requirements as such. > we've been through this about a month ago - discussing overheads and costs and scaleability of ORR on IDR mailing list. If you have some new info to add, please bring it up, otherwise it appeared we have addressed the issue positively (see archives). > Add IPv6 to this, and you have another set of administrative costs + > calculations to be made. Makes it more interesting. > if you prefer different exit for v6 than for v4, then yes - more costs, otherwise you just use option "admin cost N all-afi" and done. As for numbe= r of calculations - the amount of work is constant, whether it's cheaper/more efficient to perform this on RR or on PE is discussed earlier as mentioned above. Cheers, iLya Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trade marks of British Sky Broadcas= ting Group plc and are used under licence. British Sky Broadcasting Limited= (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554= 332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscr= ibers Services Limited (Registration No. 2340150) are direct or indirect su= bsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735)= . All of the companies mentioned in this paragraph are incorporated in Engl= and and Wales and share the same registered office at Grant Way, Isleworth,= Middlesex TW7 5QD. From Amit.Khopkar@sns.bskyb.com Tue Jun 7 03:55:13 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873DE21F84D6 for ; Tue, 7 Jun 2011 03:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-x2GumS+W0U for ; Tue, 7 Jun 2011 03:55:13 -0700 (PDT) Received: from mailfilter0.bllon.isp.sky.com (mailfilter0.bllon.isp.sky.com [90.207.250.4]) by ietfa.amsl.com (Postfix) with ESMTP id E5DB121F84D5 for ; Tue, 7 Jun 2011 03:55:12 -0700 (PDT) Received: from mailrouter0.bllon.isp.sky.com ([90.207.250.6]) by mailfilter0.bllon.isp.sky.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QTtw3-0006Dc-Sc; Tue, 07 Jun 2011 11:55:12 +0100 Received: from 5acffa6a.bb.sky.com ([90.207.250.106] helo=exch1bl.sns.bskyb.corp) by mailrouter0.bllon.isp.sky.com with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1QTtw3-0004UB-H5; Tue, 07 Jun 2011 11:54:59 +0100 Received: from exch3cl.sns.bskyb.corp ([169.254.1.94]) by exch1bl.sns.bskyb.corp ([10.244.133.22]) with mapi; Tue, 7 Jun 2011 11:54:59 +0100 From: Amit Khopkar To: iLya , Vinod Joseph Date: Tue, 7 Jun 2011 11:54:58 +0100 Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk/wveS7JikWmERg23kyzjeDxlZgAAc+3g Message-ID: References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <8E71198A8DF74C62B6C2C810B0CA5061@hnivarlas1> In-Reply-To: <8E71198A8DF74C62B6C2C810B0CA5061@hnivarlas1> 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-Mailfilter0-Spam-Score: -2.5 X-Mailman-Approved-At: Tue, 07 Jun 2011 07:48:24 -0700 Cc: "idr@ietf.org" Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:55:13 -0000 Ilya, I think Vinod has covered some options to support this requirement in an ea= rlier email. A. -----Original Message----- From: iLya [mailto:ilya@nobulus.com] Sent: 07 June 2011 11:38 To: Amit Khopkar; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflectio= n (was: Idr Digest, Vol 86, Issue 5) -------------------------------------------------- > As a network operator we believe the approach using RTs is simpler than > adding more computation and software complexity on the RR which is not > free of scalability concerns. > Amit, I am truely surprised that you as network operator don't see that RT-based proposal in its current form cannot provide full routing table. Kind regards, iLya Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trade marks of British Sky Broadcas= ting Group plc and are used under licence. British Sky Broadcasting Limited= (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554= 332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscr= ibers Services Limited (Registration No. 2340150) are direct or indirect su= bsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735)= . All of the companies mentioned in this paragraph are incorporated in Engl= and and Wales and share the same registered office at Grant Way, Isleworth,= Middlesex TW7 5QD. From Chintan.Shah@colt.net Tue Jun 7 05:02:17 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBEC11E8101 for ; Tue, 7 Jun 2011 05:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX1EedeKsvsf for ; Tue, 7 Jun 2011 05:02:16 -0700 (PDT) Received: from lonmgw06.colt-telecom.com (lonmgw06.colt-telecom.com [195.110.70.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2A06F11E80F6 for ; Tue, 7 Jun 2011 05:02:16 -0700 (PDT) Received: from lonmgw06.colt-telecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 54034FE01E2; Tue, 7 Jun 2011 13:02:15 +0100 (BST) Received: from ULVMCTMMAI052.INTERNAL.COLT.NET (unknown [10.100.109.68]) by lonmgw06.colt-telecom.com (Postfix) with ESMTP id AEF53FE01D7; Tue, 7 Jun 2011 13:02:14 +0100 (BST) Received: from ULVMCTMMAI002.INTERNAL.COLT.NET ([fe80::d4ad:601a:c5a1:f60]) by ULVMCTMMAI052.INTERNAL.COLT.NET ([::1]) with mapi id 14.01.0289.001; Tue, 7 Jun 2011 13:02:13 +0100 From: "Shah, Chintan" To: "'ilya@nobulus.com'" Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk98CRaTVzPO6jRMKTThtq6pzlBQABmliQAAAqIrAAAoICkA== Date: Tue, 7 Jun 2011 12:02:13 +0000 Message-ID: <19040_1307448135_4DEE1346_19040_17758_1_0058F6DE932DAA41B10D5E668E09A64F22CE4626@ULVMCTMMAI002.INTERNAL.COLT.NET> References: <5DD781A4BE13384A900438DF0608972C06996E1D@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996E1D@emailemea4.jnpr.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.42.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Jun 2011 07:48:24 -0700 Cc: "'idr@ietf.org'" , "Amit Khopkar \(Amit.Khopkar@sns.bskyb.com\)" , "Vinod Joseph \(vjoseph@juniper.net\)" , "Thareja, Gaurav" Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 12:02:17 -0000 Hi ilya, To add to this, As a carrier we would not like to restrict the path selecti= on only based on IGP or an administrative cost. There are diverse requireme= nts and the RT approach eases our needs to define strict, and flexible path= selection criteria based on RT constrain.=20 Another advantage with the RT approach is: Carriers with service POP deploy= ments using Anycast can load balance traffic from end user to multiple serv= ice POP through the use of RTs than just rely on IGP. There is quite an amo= unt of flexibility is there. With respect to the discussion of configurations for new ASBR/PE, once ther= e is design in place for Operation with respect a carrier network, there is= always a need for standard operational practices needed for this, and this= is something carriers are used to - when it comes to the use of RT (courte= sy VPNv4 deployments) I see it as something simpler and more flexible that = considering it a burden.=20 Regards, Chintan -----Original Message----- From: Amit Khopkar [mailto:Amit.Khopkar@sns.bskyb.com] Sent: 07 June 2011 11:35 To: iLya; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: RE: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflectio= n (was: Idr Digest, Vol 86, Issue 5) Hi Ilya, lets take a step back from the details and revisit the current situation 1. In networks with BGP-free cores the route reflector ends up making a dec= ision on the best path from its point of view and filters other paths from = being advertised to the PE. 2. BGP ADD-PATH overcomes this challenge but has some scalability concerns 3. there are two approaches to resolve this a. let the route reflector make a decision for every PE based on so= me criteria (IGP metric in your draft) b. take the RR out of the route selection process (one of the main = reasons for existence of ADD-PATH) but in a scalable manner Also the question to ask is what is optimal? is it lowest IGP metric to nex= t hop or some other criteria that the operator wishes to exercise. there sh= ould be flexibility with the network operator to support this choice. As a network operator we believe the approach using RTs is simpler than add= ing more computation and software complexity on the RR which is not free of= scalability concerns. There are pros and cons to each approach and maybe there is space for both = approaches. let the market decide what it wants ;) cheers amit -----Original Message----- From: iLya [mailto:ilya@nobulus.com] Sent: 07 June 2011 10:46 To: Vinod Joseph Cc: idr@ietf.org; Amit Khopkar; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflectio= n (was: Idr Digest, Vol 86, Issue 5) -------------------------------------------------- > Interesting enough. I just needed this to be spelt out. > > So there is enough overhead here is calculating and assigning > administrative costs between each PE-ASBR pair, if traffic flows need to > be addressed in this manner. I would imagine how easy it would be to do > this on a larger scale if there are diverse requirements as such. > we've been through this about a month ago - discussing overheads and costs and scaleability of ORR on IDR mailing list. If you have some new info to add, please bring it up, otherwise it appeared we have addressed the issue positively (see archives). > Add IPv6 to this, and you have another set of administrative costs + > calculations to be made. Makes it more interesting. > if you prefer different exit for v6 than for v4, then yes - more costs, otherwise you just use option "admin cost N all-afi" and done. As for number of calculations - the amount of work is constant, whether it's cheaper/more efficient to perform this on RR or on PE is discussed earlier as mentioned above. Cheers, iLya Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trade marks of British Sky Broadcas= ting Group plc and are used under licence. British Sky Broadcasting Limited= (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554= 332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscr= ibers Services Limited (Registration No. 2340150) are direct or indirect su= bsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735)= . All of the companies mentioned in this paragraph are incorporated in Engl= and and Wales and share the same registered office at Grant Way, Isleworth,= Middlesex TW7 5QD. [Colt Disclaimer] The message is intended for the named addressee only and may not be disclos= ed to or used by anyone else, nor may it be copied in any way. The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received th= is message in error, please advise us by e-mailing abuse@colt.net and delete t= he message and any attachments without retaining any copies. Internet communications are not secure and Colt does not accept responsibility for t= his message, its contents nor responsibility for any viruses. No contracts can = be created or varied on behalf of Colt Technology Services, its subsidiaries, group companies or affiliates ("Colt") and any other party by email communications unless expressly agreed in writing with such other party. Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900 From ju1738@att.com Tue Jun 7 08:01:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A527A11E813F for ; Tue, 7 Jun 2011 08:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO22br0SMbZ1 for ; Tue, 7 Jun 2011 08:01:48 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 958DF11E812A for ; Tue, 7 Jun 2011 08:01:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1307458907!21486057!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 8029 invoked from network); 7 Jun 2011 15:01:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 15:01:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57F0eFf019485; Tue, 7 Jun 2011 11:00:41 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57F0aWL019359; Tue, 7 Jun 2011 11:00:36 -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, 7 Jun 2011 11:01:42 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk98CRaTVzPO6jRMKTThtq6pzlBQABmliQAAlAR+A= References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net><089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> From: "UTTARO, JAMES (ATTSI)" To: "Amit Khopkar" , "iLya" , "Vinod Joseph" Cc: idr@ietf.org, Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:01:49 -0000 Could you elaborate on your concerns in re add-paths scalability?? What are the concerns? add-paths can be selectively applied, can be limited to a certain number of paths, can inter-operate with best-external where applicable, is deployable in a subset of the topology.. It would be helpful to detail your concerns and the tradeoff between creating a new paradigm that essentially duplicates what add-paths already does.. Why are RTs simpler? Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Amit Khopkar Sent: Tuesday, June 07, 2011 6:35 AM To: iLya; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Hi Ilya, lets take a step back from the details and revisit the current situation 1. In networks with BGP-free cores the route reflector ends up making a decision on the best path from its point of view and filters other paths from being advertised to the PE. 2. BGP ADD-PATH overcomes this challenge but has some scalability concerns 3. there are two approaches to resolve this a. let the route reflector make a decision for every PE based on some criteria (IGP metric in your draft) b. take the RR out of the route selection process (one of the main reasons for existence of ADD-PATH) but in a scalable manner Also the question to ask is what is optimal? is it lowest IGP metric to next hop or some other criteria that the operator wishes to exercise. there should be flexibility with the network operator to support this choice. As a network operator we believe the approach using RTs is simpler than adding more computation and software complexity on the RR which is not free of scalability concerns. There are pros and cons to each approach and maybe there is space for both approaches. let the market decide what it wants ;) cheers amit -----Original Message----- From: iLya [mailto:ilya@nobulus.com] Sent: 07 June 2011 10:46 To: Vinod Joseph Cc: idr@ietf.org; Amit Khopkar; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) -------------------------------------------------- > Interesting enough. I just needed this to be spelt out. > > So there is enough overhead here is calculating and assigning > administrative costs between each PE-ASBR pair, if traffic flows need to > be addressed in this manner. I would imagine how easy it would be to do > this on a larger scale if there are diverse requirements as such. > we've been through this about a month ago - discussing overheads and costs and scaleability of ORR on IDR mailing list. If you have some new info to add, please bring it up, otherwise it appeared we have addressed the issue positively (see archives). > Add IPv6 to this, and you have another set of administrative costs + > calculations to be made. Makes it more interesting. > if you prefer different exit for v6 than for v4, then yes - more costs, otherwise you just use option "admin cost N all-afi" and done. As for number of calculations - the amount of work is constant, whether it's cheaper/more efficient to perform this on RR or on PE is discussed earlier as mentioned above. Cheers, iLya Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the co mpanies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From vjoseph@juniper.net Tue Jun 7 08:14:13 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CF411E8119 for ; Tue, 7 Jun 2011 08:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.223 X-Spam-Level: X-Spam-Status: No, score=-5.223 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zES3u4tcTspE for ; Tue, 7 Jun 2011 08:14:12 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id C07881F0C34 for ; Tue, 7 Jun 2011 08:14:06 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTe5AO6qO/Qd07cXWmSbVqMjHIK4ahEdm@postini.com; Tue, 07 Jun 2011 08:14:12 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Tue, 7 Jun 2011 08:12:16 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 16:12:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 16:12:06 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk98CRaTVzPO6jRMKTThtq6pzlBQABmliQAAlAR+AAAFB+AA== References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net><089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> From: Vinod Joseph To: "UTTARO, JAMES (ATTSI)" , Amit Khopkar , iLya X-OriginalArrivalTime: 07 Jun 2011 15:12:12.0627 (UTC) FILETIME=[473F9A30:01CC2525] Cc: idr@ietf.org, Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:14:13 -0000 James, You are right in stating that the advertisement of ADD-PATHS can be = limited to a subset of paths.=20 However we are trying to address a totally separate issue of a BGP = speaker indicating preferences for certain paths over others. In other = words, the optimal path for a BGP speaker - which may be the based on = the IGP Metric or a path that needs to be preferred over others due to = an operators policy. =20 As part of this process, we are using RTs to indicate which paths are = needed on a per BGP speaker basis. Since the proposal is based on = ADD-PATH to have the RR advertise more than a single path, we are = proposing a mechanism to have a BGP speaker indicate its preference to = have a given number of paths on a per RT basis.=20 If we are to rely only on ADD-PATH, then the ability of a BGP speaker to = indicate affinities will not be possible - so the driver is to have a = BGP speaker the means of indicating preferences for paths - lets say as = primary, backup and so on.=20 Happy to elaborate more on this, if needed. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: UTTARO, JAMES (ATTSI) [mailto:ju1738@att.com]=20 Sent: 07 June 2011 16:02 To: Amit Khopkar; iLya; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: RE: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) Could you elaborate on your concerns in re add-paths scalability?? What are the concerns? add-paths can be selectively applied, can be limited to a certain number of paths, can inter-operate with best-external where applicable, is deployable in a subset of the topology.. It would be helpful to detail your concerns and the tradeoff between creating a new paradigm that essentially duplicates what add-paths already does.. Why are RTs simpler? Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Amit Khopkar Sent: Tuesday, June 07, 2011 6:35 AM To: iLya; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Hi Ilya, lets take a step back from the details and revisit the current situation 1. In networks with BGP-free cores the route reflector ends up making a decision on the best path from its point of view and filters other paths from being advertised to the PE. 2. BGP ADD-PATH overcomes this challenge but has some scalability concerns 3. there are two approaches to resolve this a. let the route reflector make a decision for every PE based on some criteria (IGP metric in your draft) b. take the RR out of the route selection process (one of the main reasons for existence of ADD-PATH) but in a scalable manner Also the question to ask is what is optimal? is it lowest IGP metric to next hop or some other criteria that the operator wishes to exercise. there should be flexibility with the network operator to support this choice. As a network operator we believe the approach using RTs is simpler than adding more computation and software complexity on the RR which is not free of scalability concerns. There are pros and cons to each approach and maybe there is space for both approaches. let the market decide what it wants ;) cheers amit -----Original Message----- From: iLya [mailto:ilya@nobulus.com] Sent: 07 June 2011 10:46 To: Vinod Joseph Cc: idr@ietf.org; Amit Khopkar; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) -------------------------------------------------- > Interesting enough. I just needed this to be spelt out. > > So there is enough overhead here is calculating and assigning > administrative costs between each PE-ASBR pair, if traffic flows need to > be addressed in this manner. I would imagine how easy it would be to do > this on a larger scale if there are diverse requirements as such. > we've been through this about a month ago - discussing overheads and costs and scaleability of ORR on IDR mailing list. If you have some new info to add, please bring it up, otherwise it appeared we have addressed the issue positively (see archives). > Add IPv6 to this, and you have another set of administrative costs + > calculations to be made. Makes it more interesting. > if you prefer different exit for v6 than for v4, then yes - more costs, otherwise you just use option "admin cost N all-afi" and done. As for number of calculations - the amount of work is constant, whether it's cheaper/more efficient to perform this on RR or on PE is discussed earlier as mentioned above. Cheers, iLya Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the co mpanies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Tue Jun 7 08:22:27 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5521F84A0 for ; Tue, 7 Jun 2011 08:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRr6YV93KlX9 for ; Tue, 7 Jun 2011 08:22:26 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id A72AD21F84C1 for ; Tue, 7 Jun 2011 08:22:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1307460135!21494011!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 30134 invoked from network); 7 Jun 2011 15:22:15 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 15:22:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57FL8D1023183; Tue, 7 Jun 2011 11:21:09 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57FL6uh023168; Tue, 7 Jun 2011 11:21:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 11:19:32 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A9498@misout7msgusr7e.ugd.att.com> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk98CRaTVzPO6jRMKTThtq6pzlBQABmliQAAlAR+AAAFB+AAAAVVGg References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net><089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> From: "UTTARO, JAMES (ATTSI)" To: "Vinod Joseph" , "Amit Khopkar" , "iLya" Cc: idr@ietf.org, Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:22:27 -0000 I think it is important to be clear as to the drivers. So there is = clearly no issue with add-paths scalability. I guess I am still a bit = lost as to the driver.. You seem to want to be able to prefer a path or = set of paths on an intermediate speaker ( RR ) prior to advertising = further downstream.. It would seem that add-paths and some CV scheme and = routing policy would accomplish the same goal.. If you are using = add-paths on the RRs you can send as many paths as you want and only = apply policy on the ingress PE.. I will take a read on the draft before commenting further.=20 Jim Uttaro -----Original Message----- From: Vinod Joseph [mailto:vjoseph@juniper.net]=20 Sent: Tuesday, June 07, 2011 11:12 AM To: UTTARO, JAMES (ATTSI); Amit Khopkar; iLya Cc: idr@ietf.org; Laurent Lavallee Subject: RE: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) James, You are right in stating that the advertisement of ADD-PATHS can be = limited to a subset of paths.=20 However we are trying to address a totally separate issue of a BGP = speaker indicating preferences for certain paths over others. In other = words, the optimal path for a BGP speaker - which may be the based on = the IGP Metric or a path that needs to be preferred over others due to = an operators policy. =20 As part of this process, we are using RTs to indicate which paths are = needed on a per BGP speaker basis. Since the proposal is based on = ADD-PATH to have the RR advertise more than a single path, we are = proposing a mechanism to have a BGP speaker indicate its preference to = have a given number of paths on a per RT basis.=20 If we are to rely only on ADD-PATH, then the ability of a BGP speaker to = indicate affinities will not be possible - so the driver is to have a = BGP speaker the means of indicating preferences for paths - lets say as = primary, backup and so on.=20 Happy to elaborate more on this, if needed. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: UTTARO, JAMES (ATTSI) [mailto:ju1738@att.com]=20 Sent: 07 June 2011 16:02 To: Amit Khopkar; iLya; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: RE: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) Could you elaborate on your concerns in re add-paths scalability?? What are the concerns? add-paths can be selectively applied, can be limited to a certain number of paths, can inter-operate with best-external where applicable, is deployable in a subset of the topology.. It would be helpful to detail your concerns and the tradeoff between creating a new paradigm that essentially duplicates what add-paths already does.. Why are RTs simpler? Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Amit Khopkar Sent: Tuesday, June 07, 2011 6:35 AM To: iLya; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Hi Ilya, lets take a step back from the details and revisit the current situation 1. In networks with BGP-free cores the route reflector ends up making a decision on the best path from its point of view and filters other paths from being advertised to the PE. 2. BGP ADD-PATH overcomes this challenge but has some scalability concerns 3. there are two approaches to resolve this a. let the route reflector make a decision for every PE based on some criteria (IGP metric in your draft) b. take the RR out of the route selection process (one of the main reasons for existence of ADD-PATH) but in a scalable manner Also the question to ask is what is optimal? is it lowest IGP metric to next hop or some other criteria that the operator wishes to exercise. there should be flexibility with the network operator to support this choice. As a network operator we believe the approach using RTs is simpler than adding more computation and software complexity on the RR which is not free of scalability concerns. There are pros and cons to each approach and maybe there is space for both approaches. let the market decide what it wants ;) cheers amit -----Original Message----- From: iLya [mailto:ilya@nobulus.com] Sent: 07 June 2011 10:46 To: Vinod Joseph Cc: idr@ietf.org; Amit Khopkar; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) -------------------------------------------------- > Interesting enough. I just needed this to be spelt out. > > So there is enough overhead here is calculating and assigning > administrative costs between each PE-ASBR pair, if traffic flows need to > be addressed in this manner. I would imagine how easy it would be to do > this on a larger scale if there are diverse requirements as such. > we've been through this about a month ago - discussing overheads and costs and scaleability of ORR on IDR mailing list. If you have some new info to add, please bring it up, otherwise it appeared we have addressed the issue positively (see archives). > Add IPv6 to this, and you have another set of administrative costs + > calculations to be made. Makes it more interesting. > if you prefer different exit for v6 than for v4, then yes - more costs, otherwise you just use option "admin cost N all-afi" and done. As for number of calculations - the amount of work is constant, whether it's cheaper/more efficient to perform this on RR or on PE is discussed earlier as mentioned above. Cheers, iLya Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the co mpanies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From vjoseph@juniper.net Tue Jun 7 08:37:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADC211E815A for ; Tue, 7 Jun 2011 08:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.12 X-Spam-Level: X-Spam-Status: No, score=-5.12 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksEtpa-IT-ed for ; Tue, 7 Jun 2011 08:37:32 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 36F7B11E8118 for ; Tue, 7 Jun 2011 08:37:26 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTe5FtSko5exdgfI0pFaVvLIUuabE5+in@postini.com; Tue, 07 Jun 2011 08:37:32 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Tue, 7 Jun 2011 08:34:44 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 16:34:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 16:34:37 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996F3E@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Thread-Index: Acwk98CRaTVzPO6jRMKTThtq6pzlBQABmliQAAlAR+AAAFB+AAAAVVGgAAB3fcA= References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net><089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> <1477DEAE19DD884CB004730D0FD77FD7041A9498@misout7msgusr7e.ugd.att.com> From: Vinod Joseph To: "UTTARO, JAMES (ATTSI)" , Amit Khopkar , iLya X-OriginalArrivalTime: 07 Jun 2011 15:34:42.0359 (UTC) FILETIME=[6BC05C70:01CC2528] Cc: idr@ietf.org, Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:37:33 -0000 Please do. The driver and discussion is surely not about Add-Path. One thing is, we do not want to have the RR announce all paths to the PE = and then use policies to choose lets say 2 out of 10 paths. Also, if a BGP speaker (PE) does not use Add-Path - the solution = provides a means of having it indicate preferences for selective exit = points via RT constrain. In this case it is expected that the RR would = announce those ASBR NHs to the PEs. However since Add-Path is not = supported on the PE, the RR would choose a NH which it considers the = best (that is only in the event of multiple ASBRs having the same RT). Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: UTTARO, JAMES (ATTSI) [mailto:ju1738@att.com]=20 Sent: 07 June 2011 16:20 To: Vinod Joseph; Amit Khopkar; iLya Cc: idr@ietf.org; Laurent Lavallee Subject: RE: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) I think it is important to be clear as to the drivers. So there is = clearly no issue with add-paths scalability. I guess I am still a bit = lost as to the driver.. You seem to want to be able to prefer a path or = set of paths on an intermediate speaker ( RR ) prior to advertising = further downstream.. It would seem that add-paths and some CV scheme and = routing policy would accomplish the same goal.. If you are using = add-paths on the RRs you can send as many paths as you want and only = apply policy on the ingress PE.. I will take a read on the draft before commenting further.=20 Jim Uttaro -----Original Message----- From: Vinod Joseph [mailto:vjoseph@juniper.net]=20 Sent: Tuesday, June 07, 2011 11:12 AM To: UTTARO, JAMES (ATTSI); Amit Khopkar; iLya Cc: idr@ietf.org; Laurent Lavallee Subject: RE: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) James, You are right in stating that the advertisement of ADD-PATHS can be = limited to a subset of paths.=20 However we are trying to address a totally separate issue of a BGP = speaker indicating preferences for certain paths over others. In other = words, the optimal path for a BGP speaker - which may be the based on = the IGP Metric or a path that needs to be preferred over others due to = an operators policy. =20 As part of this process, we are using RTs to indicate which paths are = needed on a per BGP speaker basis. Since the proposal is based on = ADD-PATH to have the RR advertise more than a single path, we are = proposing a mechanism to have a BGP speaker indicate its preference to = have a given number of paths on a per RT basis.=20 If we are to rely only on ADD-PATH, then the ability of a BGP speaker to = indicate affinities will not be possible - so the driver is to have a = BGP speaker the means of indicating preferences for paths - lets say as = primary, backup and so on.=20 Happy to elaborate more on this, if needed. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: UTTARO, JAMES (ATTSI) [mailto:ju1738@att.com]=20 Sent: 07 June 2011 16:02 To: Amit Khopkar; iLya; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: RE: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol = 86, Issue 5) Could you elaborate on your concerns in re add-paths scalability?? What are the concerns? add-paths can be selectively applied, can be limited to a certain number of paths, can inter-operate with best-external where applicable, is deployable in a subset of the topology.. It would be helpful to detail your concerns and the tradeoff between creating a new paradigm that essentially duplicates what add-paths already does.. Why are RTs simpler? Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Amit Khopkar Sent: Tuesday, June 07, 2011 6:35 AM To: iLya; Vinod Joseph Cc: idr@ietf.org; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) Hi Ilya, lets take a step back from the details and revisit the current situation 1. In networks with BGP-free cores the route reflector ends up making a decision on the best path from its point of view and filters other paths from being advertised to the PE. 2. BGP ADD-PATH overcomes this challenge but has some scalability concerns 3. there are two approaches to resolve this a. let the route reflector make a decision for every PE based on some criteria (IGP metric in your draft) b. take the RR out of the route selection process (one of the main reasons for existence of ADD-PATH) but in a scalable manner Also the question to ask is what is optimal? is it lowest IGP metric to next hop or some other criteria that the operator wishes to exercise. there should be flexibility with the network operator to support this choice. As a network operator we believe the approach using RTs is simpler than adding more computation and software complexity on the RR which is not free of scalability concerns. There are pros and cons to each approach and maybe there is space for both approaches. let the market decide what it wants ;) cheers amit -----Original Message----- From: iLya [mailto:ilya@nobulus.com] Sent: 07 June 2011 10:46 To: Vinod Joseph Cc: idr@ietf.org; Amit Khopkar; Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection (was: Idr Digest, Vol 86, Issue 5) -------------------------------------------------- > Interesting enough. I just needed this to be spelt out. > > So there is enough overhead here is calculating and assigning > administrative costs between each PE-ASBR pair, if traffic flows need to > be addressed in this manner. I would imagine how easy it would be to do > this on a larger scale if there are diverse requirements as such. > we've been through this about a month ago - discussing overheads and costs and scaleability of ORR on IDR mailing list. If you have some new info to add, please bring it up, otherwise it appeared we have addressed the issue positively (see archives). > Add IPv6 to this, and you have another set of administrative costs + > calculations to be made. Makes it more interesting. > if you prefer different exit for v6 than for v4, then yes - more costs, otherwise you just use option "admin cost N all-afi" and done. As for number of calculations - the amount of work is constant, whether it's cheaper/more efficient to perform this on RR or on PE is discussed earlier as mentioned above. Cheers, iLya Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the co mpanies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Tue Jun 7 09:24:32 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B53611E8168 for ; Tue, 7 Jun 2011 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.318 X-Spam-Level: X-Spam-Status: No, score=-10.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9+FQni5Nqhs for ; Tue, 7 Jun 2011 09:24:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id B6FAA11E812A for ; Tue, 7 Jun 2011 09:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1470; q=dns/txt; s=iport; t=1307463871; x=1308673471; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4WYdB7ps6w9cnGwKGwU6/NdwaCFm1zbuQbf11F73tsY=; b=XaM+mvXCHbCJTwl65V9NW4QktF8OPd8m6MCHkBQAKDk/aogcsSe7Luok 3HpTKovHBXltnYg3w85KP0NeCstBkwuv6bIUhpwguRjEnMUDBoyELEeqs 5u9YCmu7YDxx1eMzFPtBipHqxrM/bl7ffA8Bv3uvrG9jyk9lEgY1Fg+uN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADdQ7k2rRDoI/2dsb2JhbABSph93iHGjXIJ+DwGbEoYhBJEKhEyKew X-IronPort-AV: E=Sophos;i="4.65,333,1304294400"; d="scan'208";a="371946673" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2011 16:24:31 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p57GOT62011540; Tue, 7 Jun 2011 16:24:30 GMT Message-ID: <4DEE50D0.6070608@cisco.com> Date: Tue, 07 Jun 2011 18:24:48 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Amit Khopkar References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" , Vinod Joseph , Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:24:32 -0000 Hi Amit, > 3. there are two approaches to resolve this a. let the route > reflector make a decision for every PE based on some criteria (IGP > metric in your draft) b. take the RR out of the route selection > process (one of the main reasons for existence of ADD-PATH) but in a > scalable manner Since Chintan is also apparently in the same assumption let me reiterate that base ORR IDR WG draft can use IGP metric or angular distance approximation techniques to select optimal paths. Now if optimal for an operator means to use his other criteria the NH-SAFI draft Ilya and I wrote comes handy as "metric" which PE replies to RR is just a number. Yes it could be related to IGP view of PE to such next hop, but equally well it can be related to operator's local policy. Such local policy needs to be configured and expressed somehow. Your draft recommends configuring RT to match what said ASBRs would use in route marking what clearly is more complex then allocating local value as local value does not require a correlation with any other network entity. That seems to be a difference you are not seeing. The bottom line IDR WG draft + draft-varlashkin-bgp-nh-cost already address all possible scenarios which you may need by using your draft. If there is something in your draft which the above set is missing and which by using the above two drafts could not be accomplished please clearly explain. Many thx, R. From raszuk@cisco.com Tue Jun 7 09:38:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B819C11E816C for ; Tue, 7 Jun 2011 09:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.344 X-Spam-Level: X-Spam-Status: No, score=-10.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSaY0xzeO-ic for ; Tue, 7 Jun 2011 09:38:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3517011E816A for ; Tue, 7 Jun 2011 09:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=620; q=dns/txt; s=iport; t=1307464682; x=1308674282; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hNPwSuLsYrTNtw8PvKGeUGJF1nRdZNyh+xkFbAzIiu4=; b=XL9lz+ohmuF8cjOuCDawYVlFmKIsvxCVUOvCns6u1uk4MMMf3iN4TDuu YKxP+llK5SWg3B1rSqIBovLoFxcjicIurLWirHN0vPgbv73u7Oes4m8rA 0+l1xCJQVTlqhMnXvhWlH9ocAsZkkzzx+nNsG9F5xG3/XTAr5/H4A1X1K Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJFS7k2rRDoI/2dsb2JhbABSph93iHGjWoJ+DwGbEoYhBJEKhEyKew X-IronPort-AV: E=Sophos;i="4.65,333,1304294400"; d="scan'208";a="371957238" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2011 16:37:23 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p57GbMgm024059; Tue, 7 Jun 2011 16:37:22 GMT Message-ID: <4DEE53D5.6020800@cisco.com> Date: Tue, 07 Jun 2011 18:37:41 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "UTTARO, JAMES (ATTSI)" References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net><089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> <1477DEAE19DD884CB004730D0FD77FD7041A9498@misout7msgusr7e.ugd.att.com> In-Reply-To: <1477DEAE19DD884CB004730D0FD77FD7041A9498@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: [Idr] Send only what is needed or send all then drop inbound ... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:38:03 -0000 Hi Jim, > If > you are using add-paths on the RRs you can send as many paths as you > want and only apply policy on the ingress PE.. While we are a bit diverging from the main topic (new subject) I would be very interested in understanding your opinion on why would you recommend to perform send all followed by inbound drop for Internet prefixes to avoid storing information which is not necessary on PEs while in the same time you do recommend to use RT-Constraint or similar approaches to enforce send only what is required and avoid inbound drop for VPNv4/VPNv6 prefixes ? Best regards, R. From ju1738@att.com Tue Jun 7 10:03:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBC211E81D7 for ; Tue, 7 Jun 2011 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqPVn0Xb3c6g for ; Tue, 7 Jun 2011 10:03:48 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7C611E81BE for ; Tue, 7 Jun 2011 10:03:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1307466227!21441059!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 6551 invoked from network); 7 Jun 2011 17:03:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 17:03:47 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57H2eSU008597 for ; Tue, 7 Jun 2011 13:02:41 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57H2aEA008501 for ; Tue, 7 Jun 2011 13:02:36 -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, 7 Jun 2011 13:03:42 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A949B@misout7msgusr7e.ugd.att.com> In-Reply-To: <4DEE53D5.6020800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Send only what is needed or send all then drop inbound ... Thread-Index: AcwlMTKyt0MY2pQUR6iInK/I3HlHCAAACH2A References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net><089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> <1477DEAE19DD884CB004730D0FD77FD7041A9498@misout7msgusr7e.ugd.att.com> <4DEE53D5.6020800@cisco.com> From: "UTTARO, JAMES (ATTSI)" To: Cc: idr@ietf.org Subject: Re: [Idr] Send only what is needed or send all then drop inbound ... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:03:49 -0000 Robert I think there is a bit of a disconnect on use cases for add-paths. In my mind add-paths is a surgical instrument akin to a scalpel that allows for high value paths to be propagated through a topology. There are various service enhancements/features ( Load Balancing, Fast Convergence, Primary/Backup etc.. ) that could be monetized or act as a differentiator. With that in mind a small subset of paths are allowed to propagate through the topology and each ingress PE would receive multiple paths. This is no different than the use of a unique RD in a VPNV4 in terms of learning multiple paths at a PE although one could argue there are different routing contexts and the nature of a VPN would mean less paths less paths.. Regardless I would never allow add-paths to operate on the entire IPV4 routing domain it would never scale on RRs or PEs. Your comment "... inbound drop for Internet prefixes to avoid storing information which is not necessary on PEs" is not correct.. In a Load Balancing arrangement multiple paths would be used also having multiple paths on a PE Primary/Backup would speed convergence considerably as the ingress PE would only need to have the primary withdrawn part of the with-drawl/advertisement cycle as the backup path is already on the ingress and does not need to be re-advertised from the backup egress PE. My thoughts on RT Constrain is that the base assumption is incorrect. RT Constrain was envisioned as creating VPN distribution graphs that would reduce the state in parts of the topology that did not require certain VPN routing state. The thinking here is that it provided a method to scale routing state. RT Constrains "strength" is that it hides path information from speakers that are not "interested" in it by virtue of a VRF not being defined on a given PE.. But it is actually a weakness in that it precludes the ability to provide high value services such as stitching content between two VPNs.. Cloud, Content Based etc... services that require "seeing" all of the routing state are examples. I do believe RT Constrain is useful but only if there is also a mechanism to force the distribution of routes regardless of whether or not a given speaker "requires' it. Of course there are other issues i.e New AF needs to be deployed, have to accommodate speakers that are legacy, NM needs to be built to "know" what RT Constrain is doing is correct etc... I do not understand why RT Constrain is being brought up in the context of this conversation with Vinod.=20 Jim Uttaro -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: Tuesday, June 07, 2011 12:38 PM To: UTTARO, JAMES (ATTSI) Cc: idr@ietf.org Subject: Send only what is needed or send all then drop inbound ... Hi Jim, > If > you are using add-paths on the RRs you can send as many paths as you > want and only apply policy on the ingress PE.. While we are a bit diverging from the main topic (new subject) I would=20 be very interested in understanding your opinion on why would you=20 recommend to perform send all followed by inbound drop for Internet=20 prefixes to avoid storing information which is not necessary on PEs=20 while in the same time you do recommend to use RT-Constraint or similar=20 approaches to enforce send only what is required and avoid inbound drop=20 for VPNv4/VPNv6 prefixes ? Best regards, R. From raszuk@cisco.com Tue Jun 7 10:15:34 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BD221F8467 for ; Tue, 7 Jun 2011 10:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eqc2D3Bh0cF for ; Tue, 7 Jun 2011 10:15:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC7E821F8482 for ; Tue, 7 Jun 2011 10:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4599; q=dns/txt; s=iport; t=1307466926; x=1308676526; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ADUWcJoDMCa3JC7vNx7FDZ+XsAs/WH99gsoW3A+U6Fw=; b=gQNWAt8U7+DG166Od5rWYMOkP4x9/AAyXrGHtg2UtcMqLE+j2kpa+sv6 XalSqDko1/05KdhA0o2wVmzNHjtYIGzNAAEigEIa6iE+sRMtFIxZUnT6U bZ2JH9C6CY0JDpeWMZ+Se2LqqEF87zVFjDuxIvKEQapmwXR4BY/+Luv4l M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAEhb7k2Q/khL/2dsb2JhbABTlzaOaXeIcaM4gn4PAZsIhiEEkQqETIp7 X-IronPort-AV: E=Sophos;i="4.65,333,1304294400"; d="scan'208";a="34109785" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 07 Jun 2011 17:15:25 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p57HFNmG020591; Tue, 7 Jun 2011 17:15:24 GMT Message-ID: <4DEE5CBE.9060408@cisco.com> Date: Tue, 07 Jun 2011 19:15:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "UTTARO, JAMES (ATTSI)" References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net><089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> <1477DEAE19DD884CB004730D0FD77FD7041A9498@misout7msgusr7e.ugd.att.com> <4DEE53D5.6020800@cisco.com> <1477DEAE19DD884CB004730D0FD77FD7041A949B@misout7msgusr7e.ugd.att.com> In-Reply-To: <1477DEAE19DD884CB004730D0FD77FD7041A949B@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Send only what is needed or send all then drop inbound ... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:15:34 -0000 Jim, > Your comment "... inbound drop for Internet prefixes to avoid storing > information which is not necessary on PEs" is not correct.. In a Load > Balancing arrangement multiple paths would be used also having > multiple Allow me to clarify ... when I specifically said "to avoid storing information which is not necessary on PEs" I meant the case where those paths would never be used by PE for example you have 30 paths in the network for a given destination and you at most like to load-balance to 4 of them. Or just like you recommended paths could be defined as not necessary if it would be inbound drop as you have recommended. > I do not understand why RT Constrain is being brought up in the > context of this conversation with Vinod. His entire draft uses RT-Constrain for filtering IPv4/IPv6 unicast/multicast paths on a per RR client basis :) Many thx, R. > Robert > > I think there is a bit of a disconnect on use cases for add-paths. In my > mind add-paths is a surgical instrument akin to a scalpel that allows > for high value paths to be propagated through a topology. There are > various service enhancements/features ( Load Balancing, Fast > Convergence, Primary/Backup etc.. ) that could be monetized or act as a > differentiator. With that in mind a small subset of paths are allowed > to propagate through the topology and each ingress PE would receive > multiple paths. This is no different than the use of a unique RD in a > VPNV4 in terms of learning multiple paths at a PE although one could > argue there are different routing contexts and the nature of a VPN would > mean less paths less paths.. Regardless I would never allow add-paths to > operate on the entire IPV4 routing domain it would never scale on RRs or > PEs. > > Your comment "... inbound drop for Internet prefixes to avoid storing > information which is not necessary on PEs" is not correct.. In a Load > Balancing arrangement multiple paths would be used also having multiple > paths on a PE Primary/Backup would speed convergence considerably as the > ingress PE would only need to have the primary withdrawn part of the > with-drawl/advertisement cycle as the backup path is already on the > ingress and does not need to be re-advertised from the backup egress PE. > > My thoughts on RT Constrain is that the base assumption is incorrect. RT > Constrain was envisioned as creating VPN distribution graphs that would > reduce the state in parts of the topology that did not require certain > VPN routing state. The thinking here is that it provided a method to > scale routing state. RT Constrains "strength" is that it hides path > information from speakers that are not "interested" in it by virtue of a > VRF not being defined on a given PE.. But it is actually a weakness in > that it precludes the ability to provide high value services such as > stitching content between two VPNs.. Cloud, Content Based etc... > services that require "seeing" all of the routing state are examples. I > do believe RT Constrain is useful but only if there is also a mechanism > to force the distribution of routes regardless of whether or not a given > speaker "requires' it. Of course there are other issues i.e New AF needs > to be deployed, have to accommodate speakers that are legacy, NM needs > to be built to "know" what RT Constrain is doing is correct etc... > > I do not understand why RT Constrain is being brought up in the context > of this conversation with Vinod. > > Jim Uttaro > > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Tuesday, June 07, 2011 12:38 PM > To: UTTARO, JAMES (ATTSI) > Cc: idr@ietf.org > Subject: Send only what is needed or send all then drop inbound ... > > Hi Jim, > > > If >> you are using add-paths on the RRs you can send as many paths as you >> want and only apply policy on the ingress PE.. > > While we are a bit diverging from the main topic (new subject) I would > be very interested in understanding your opinion on why would you > recommend to perform send all followed by inbound drop for Internet > prefixes to avoid storing information which is not necessary on PEs > while in the same time you do recommend to use RT-Constraint or similar > approaches to enforce send only what is required and avoid inbound drop > for VPNv4/VPNv6 prefixes ? > > Best regards, > R. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From ju1738@att.com Tue Jun 7 10:19:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAA921F848E for ; Tue, 7 Jun 2011 10:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.832 X-Spam-Level: X-Spam-Status: No, score=-105.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKP8XiyENkU4 for ; Tue, 7 Jun 2011 10:18:59 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4B16A21F846F for ; Tue, 7 Jun 2011 10:18:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1307467138!22973149!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13120 invoked from network); 7 Jun 2011 17:18:58 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 17:18:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57HHqqJ029011 for ; Tue, 7 Jun 2011 13:17:52 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57HHkEJ028934 for ; Tue, 7 Jun 2011 13:17: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, 7 Jun 2011 13:18:52 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A949D@misout7msgusr7e.ugd.att.com> In-Reply-To: <4DEE5CBE.9060408@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Send only what is needed or send all then drop inbound ... Thread-Index: AcwlNoOsQHr4uLAuRFCuk/u/c7XI1QAAB7rA References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net><089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> <1477DEAE19DD884CB004730D0FD77FD7041A9498@misout7msgusr7e.ugd.att.com> <4DEE53D5.6020800@cisco.com> <1477DEAE19DD884CB004730D0FD77FD7041A949B@misout7msgusr7e.ugd.att.com> <4DEE5CBE.9060408@cisc o.com> From: "UTTARO, JAMES (ATTSI)" To: Cc: idr@ietf.org Subject: Re: [Idr] Send only what is needed or send all then drop inbound ... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:19:00 -0000 Robert, Comments In-Line Jim Uttaro.. -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: Tuesday, June 07, 2011 1:16 PM To: UTTARO, JAMES (ATTSI) Cc: idr@ietf.org Subject: Re: [Idr] Send only what is needed or send all then drop inbound ... Jim, > Your comment "... inbound drop for Internet prefixes to avoid storing > information which is not necessary on PEs" is not correct.. In a Load > Balancing arrangement multiple paths would be used also having > multiple Allow me to clarify ... when I specifically said "to avoid storing=20 information which is not necessary on PEs" I meant the case where those=20 paths would never be used by PE for example you have 30 paths in the=20 network for a given destination and you at most like to load-balance to=20 4 of them. Or just like you recommended paths could be defined as not=20 necessary if it would be inbound drop as you have recommended. [Jim U>] I would never send all thirty of the paths.. If four is needed for Load balancing then I would configure add-paths with n=3D4.. I would not allow add-paths to be deployed without constraining the number of paths as I stated in my previous e-mail.. > I do not understand why RT Constrain is being brought up in the > context of this conversation with Vinod. His entire draft uses RT-Constrain for filtering IPv4/IPv6=20 unicast/multicast paths on a per RR client basis :) [Jim U>] Yup I took a quick read and got it. Many thx, R. > Robert > > I think there is a bit of a disconnect on use cases for add-paths. In my > mind add-paths is a surgical instrument akin to a scalpel that allows > for high value paths to be propagated through a topology. There are > various service enhancements/features ( Load Balancing, Fast > Convergence, Primary/Backup etc.. ) that could be monetized or act as a > differentiator. With that in mind a small subset of paths are allowed > to propagate through the topology and each ingress PE would receive > multiple paths. This is no different than the use of a unique RD in a > VPNV4 in terms of learning multiple paths at a PE although one could > argue there are different routing contexts and the nature of a VPN would > mean less paths less paths.. Regardless I would never allow add-paths to > operate on the entire IPV4 routing domain it would never scale on RRs or > PEs. > > Your comment "... inbound drop for Internet prefixes to avoid storing > information which is not necessary on PEs" is not correct.. In a Load > Balancing arrangement multiple paths would be used also having multiple > paths on a PE Primary/Backup would speed convergence considerably as the > ingress PE would only need to have the primary withdrawn part of the > with-drawl/advertisement cycle as the backup path is already on the > ingress and does not need to be re-advertised from the backup egress PE. > > My thoughts on RT Constrain is that the base assumption is incorrect. RT > Constrain was envisioned as creating VPN distribution graphs that would > reduce the state in parts of the topology that did not require certain > VPN routing state. The thinking here is that it provided a method to > scale routing state. RT Constrains "strength" is that it hides path > information from speakers that are not "interested" in it by virtue of a > VRF not being defined on a given PE.. But it is actually a weakness in > that it precludes the ability to provide high value services such as > stitching content between two VPNs.. Cloud, Content Based etc... > services that require "seeing" all of the routing state are examples. I > do believe RT Constrain is useful but only if there is also a mechanism > to force the distribution of routes regardless of whether or not a given > speaker "requires' it. Of course there are other issues i.e New AF needs > to be deployed, have to accommodate speakers that are legacy, NM needs > to be built to "know" what RT Constrain is doing is correct etc... > > I do not understand why RT Constrain is being brought up in the context > of this conversation with Vinod. > > Jim Uttaro > > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Tuesday, June 07, 2011 12:38 PM > To: UTTARO, JAMES (ATTSI) > Cc: idr@ietf.org > Subject: Send only what is needed or send all then drop inbound ... > > Hi Jim, > > > If >> you are using add-paths on the RRs you can send as many paths as you >> want and only apply policy on the ingress PE.. > > While we are a bit diverging from the main topic (new subject) I would > be very interested in understanding your opinion on why would you > recommend to perform send all followed by inbound drop for Internet > prefixes to avoid storing information which is not necessary on PEs > while in the same time you do recommend to use RT-Constraint or similar > approaches to enforce send only what is required and avoid inbound drop > for VPNv4/VPNv6 prefixes ? > > Best regards, > R. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From raszuk@cisco.com Tue Jun 7 10:33:52 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9864C21F84E5 for ; Tue, 7 Jun 2011 10:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6emFCR9un7Rc for ; Tue, 7 Jun 2011 10:33:51 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C746E21F84DA for ; Tue, 7 Jun 2011 10:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=974; q=dns/txt; s=iport; t=1307468031; x=1308677631; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JadAaGAG+C11MFXoA4cM9dDQLBVEj3xa5Xy9585ERQo=; b=FCuwzgoCZP2e9/MTdw55WjEdG1kcSyLA0ON6aB+Ap6ZHUw9iY41aH2jH +u46wCK1qJUQURgyYBfsdGfTn+/ZIi/Vq/SxrSqD2MyYjUsxsw5kxfICG ghvz1g0DHPwqJM3fwLVr+/01vy8+CsyXTGwF3rayLY3scj6GP79oJ9zHB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD5g7k2rRDoI/2dsb2JhbABTph93rBSCfg8BmwaGIQSRCoRMins X-IronPort-AV: E=Sophos;i="4.65,333,1304294400"; d="scan'208";a="332022627" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2011 17:33:51 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p57HXorS014642; Tue, 7 Jun 2011 17:33:50 GMT Message-ID: <4DEE6111.3020603@cisco.com> Date: Tue, 07 Jun 2011 19:34:09 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "UTTARO, JAMES (ATTSI)" References: <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net><44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com><5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net><2491F56A4456476FA2EDD65297696BF9@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net><5A91223E080242C3A52A6BD444BA3B90@hnivarlas1><5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net><9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <1477DEAE19DD884CB004730D0FD77FD7041A9497@misout7msgusr7e.ugd.att.com> <5DD781A4BE13384A900438DF0608972C06996F28@emailemea4.jnpr.net> <1477DEAE19DD884CB004730D0FD77FD7041A9498@misout7msgusr7e.ugd.att.com> <4DEE53D5.6020800@cisco.com> <1477DEAE19DD884CB004730D0FD77FD7041A949B@misout7msgusr7e.ugd.att.com> <4DEE5CBE.9060408@cisc o.com> <1477DEAE19DD884CB004730D0FD77FD7041A949D@misout7msgusr7e.ugd.att.com> In-Reply-To: <1477DEAE19DD884CB004730D0FD77FD7041A949D@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Send only what is needed or send all then drop inbound ... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:33:52 -0000 Hi Jim, > [Jim U>] I would never send all thirty of the paths.. If four is > needed for Load balancing then I would configure add-paths with n=4.. > I would not allow add-paths to be deployed without constraining the > number of paths as I stated in my previous e-mail.. Excellent. So to clarify further what ORR IDR WG doc and what Vinod draft was trying to find an alternative solution for is the problem of which 4 out of available 30 paths you send to a client or group of clients. Note that from each RR client or group of RR clients the set of "optimal" 4 paths may consists of a different set. That is the problem statement. It is completely orthogonal how you encode the subset of paths and naturally if you need to send more paths add-paths is the "transport" solution. It is also orthogonal on what paths are send eligible .. ie which add-path selection mode is chosen. The additional step comes after that. Many thx, R. From vjoseph@juniper.net Tue Jun 7 14:33:06 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ABF11E81B5 for ; Tue, 7 Jun 2011 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI1vWivtnxS8 for ; Tue, 7 Jun 2011 14:33:06 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAE411E80C2 for ; Tue, 7 Jun 2011 14:33:00 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTe6ZCau354OH+UpzIbRvtw+nXYBdTV+N@postini.com; Tue, 07 Jun 2011 14:33:05 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Tue, 7 Jun 2011 14:32:19 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 22:32:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 22:32:03 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95A References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> From: Vinod Joseph To: , Amit Khopkar X-OriginalArrivalTime: 07 Jun 2011 21:32:17.0770 (UTC) FILETIME=[602C44A0:01CC255A] Cc: idr@ietf.org, Laurent Lavallee Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:33:07 -0000 Robert, There has been some amount of confusion in regard to BGP speakers will = handle traffic in the event of prefixes not being available on ASBRs = that match the RT interest from a PEs perspective. Let me clarify this = here: -> Let us assume that there are 10 ASBRs in a network with two RRs (RR1 = and RR2) and each ASBR has an RT for its prefixes, and PE1 has expressed = interest in two RTs - lets say "A" and "B"(two ASBRs). The RR would = announce prefixes for these two ASBRs only to the PE, therefore in the = event of prefixes not being available at these two ASBRs - traffic may = be blackholed even though there are 8 other ASBRs available. The draft = clearly mentions that each RR can be allotted an RR specific RT. So lets = say RR1 has an RT of X and RR2 has Y. The PE1 can announce interest in = RT "X" and RT "Y" in addition to "A" and "B". This is a common = deployment where, RR1 and RR2 will both announce prefixes that match "A" = and "B" plus the best path for all prefixes that it is aware of = (Prefixes with RT extended communities and prefixes that may be = announced without RT extended community). This will ensure that PE1 = receives 2 additional paths from RR1 and RR2 which can be used as backup = in the event of prefixes not being available from RT "A" and "B". This = will ensure that traffic will never be black-holed at all (until viable = paths exist). -> Whether a network entity or local is a matter of how much = administrative overhead vs. flexibility can be achieved. In the case of = the NH draft, each PE needs to be configured with an administrative = distance to each ASBR - if we need to achieve something similar to what = can be achieved by using RTs. This can be complex, since we would end up = calculating each pair (PE-ASBR) in addition to traffic flows needed to = put in values. On the contrary use of RTs is nothing new for operators. = Using appropriate RTs would be the only step involved in receiving ASBR = paths. Addition of new paths, means - just adding another RT interest or = removing it etc and does not involve re-engineering metrics.=20 -> RT uses existing BGP machinery, therefore an operator does not need = to worry about the support of a new capability.=20 -> This solution proposes a scheme of announcing affinities, even in the = case of ADD-PATH not being supported on PEs - which is an advantage. So = a PE can just indicate an RT that matches an ASBR that is closest or = administratively preferred and still get that path announced by the RR. = In addition RR specific RTs (as mentioned above) can provide backup in = the event of the preferred ASBR losing prefixes or going offline. -> De-coupling the RR from path selection through intelligent requests = through affinities can certainly reduce the overhead on the RR + the = churn caused on the RR due to SPF runs. -> It is the ease of adoption - since RT has been deployed for a while = now which makes it simpler. A updated version (01) of the draft elaborating some of these scenarios = in large detail will be released shortly. Regards Vinod Joseph Professional Services - Service Provider EMEA Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 07 June 2011 17:25 To: Amit Khopkar Cc: iLya; Vinod Joseph; idr@ietf.org; Laurent Lavallee Subject: Re: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection Hi Amit, > 3. there are two approaches to resolve this a. let the route > reflector make a decision for every PE based on some criteria (IGP > metric in your draft) b. take the RR out of the route selection > process (one of the main reasons for existence of ADD-PATH) but in a > scalable manner Since Chintan is also apparently in the same assumption let me reiterate = that base ORR IDR WG draft can use IGP metric or angular distance=20 approximation techniques to select optimal paths. Now if optimal for an operator means to use his other criteria the=20 NH-SAFI draft Ilya and I wrote comes handy as "metric" which PE replies=20 to RR is just a number. Yes it could be related to IGP view of PE to=20 such next hop, but equally well it can be related to operator's local=20 policy. Such local policy needs to be configured and expressed somehow. Your=20 draft recommends configuring RT to match what said ASBRs would use in=20 route marking what clearly is more complex then allocating local value=20 as local value does not require a correlation with any other network=20 entity. That seems to be a difference you are not seeing. The bottom line IDR WG draft + draft-varlashkin-bgp-nh-cost already=20 address all possible scenarios which you may need by using your draft. If there is something in your draft which the above set is missing and=20 which by using the above two drafts could not be accomplished please=20 clearly explain. Many thx, R. From vjoseph@juniper.net Tue Jun 7 17:38:54 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB95D11E80FE for ; Tue, 7 Jun 2011 17:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.925 X-Spam-Level: X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meccpkYKnHfk for ; Tue, 7 Jun 2011 17:38:53 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF9F11E80F8 for ; Tue, 7 Jun 2011 17:38:46 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTe7EkI7FBhFu5XqhLAARIfuxrSsyg2OO@postini.com; Tue, 07 Jun 2011 17:38:49 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Tue, 7 Jun 2011 17:36:58 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 01:36:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 8 Jun 2011 01:36:56 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95AAAcV0Sk= From: Vinod Joseph To: , X-OriginalArrivalTime: 08 Jun 2011 00:36:56.0654 (UTC) FILETIME=[2BB3CEE0:01CC2574] Cc: idr@ietf.org, Gaurav.Thareja@colt.net, Chintan.Shah@colt.net, Laurent.Lavallee@sns.bskyb.com Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 00:38:54 -0000 RnVydGhlciBlbGFib3JhdGluZyBvbiB0aGUgYW1vdW50IG9mIGNvbmZpZ3VyYXRpb25zIHJlcXVp cmVkIGluIHRoaXMgZHJhZnQgdnMgdGhlIG90aGVyIHByb3Bvc2Fscy4NCg0KT25seSBBU0JScyBu ZWVkIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCBSb3V0ZSB0YXJnZXRzIHdoZW4gYWR2ZXJ0aXNlZCB0 byB0aGUgUlJzLCBhbmQgSSBhbSBzdXJlIEFTQlJzIGFyZSBtdWNoIGZld2VyIGluIG51bWJlciB0 byBQRXMuIFRoZSBQRXMgb25seSBzaWduYWwgaW50ZXJlc3QgdmlhIFJUIGNvbnN0cmFpbiBhbmQg ZG8gbm90IG5lZWQgdG8gYXR0YWNoIFJUcyB0byB0aGVpciBsb2NhbCBwcmVmaXhlcy4gVGhlIHJl YXNvbjogSW4gbW9zdCBjYXNlcyBQRSBhbm5vdW5jZWQgY3VzdG9tZXIgcHJlZml4ZXMgY2FuIGJl IGNvbnRyb2xsZWQgdXNpbmcgc3RhbmRhcmQgQkdQIG1ldGhvZHMsIGlmIHRoZXNlIFBFIGFubm91 bmNlZCBwcmVmaXhlcyBhcmUgbm90IG5lZWRlZCBvbiBhbiBBU0JSIGZvciBzb21lIHNwZWNpYWwg cmVhc29uLg0KDQpPbiB0aGUgY29udHJhcnksIHRoZSBvdGhlciBzb2x1dGlvbiBuZWVkcyBldmVy eSBQRSB0byBBU0JSIHBhaXIgbWFwcGVkIHdpdGggYW4gYWRtaW5pc3RyYXRpdmUgY29zdCBpbiBj YXNlcyB3aGVyZSB0aGUgSUdQIGlzIG5vdCBwcmVmZXJyZWQgZm9yIHVzZS4gSWYgeW91IGhhdmUg c2l0dWF0aW9ucyB3aGVyZSBlYWNoIFBFIG9yIGdyb3VwcyBvZiBQRXMgaGF2ZSBkaXZlcnNlIG91 dGJvdW5kIHRyYWZmaWMgZmxvdyByZXF1aXJlbWVudHMsIHlvdSB3b3VsZCBlbmQgdXAgaGF2aW5n IHRvIG1hbnVhbGx5IHNldHVwIHBvdGVudGlhbGx5IGh1Z2UgbnVtYmVyIG9mIFBFK0FTQlIgcGFp cnMuIEluIHRoZSBldmVudCBvZiBhIG5ldyBBU0JSIGludHJvZHVjZWQgaW4gdGhlIG5ldHdvcmss IGFsbCBQRXMgdGhhdCBuZWVkIHRvIHVzZSB0aGlzIEFTQlIgYXMgYSBwcmltYXJ5IGV4aXQgcG9p bnQgd2lsbCBuZWVkIHJlY29uZmlndXJhdGlvbi4gVXNpbmcgUlQsIG9ubHkgdGhlIEFTQlIgd2ls bCBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQgdG8gYWR2ZXJ0aXNlIGl0cyBwYXRocyB3aXRoIGFuIGFk ZGl0aW9uYWwgUm91dGUgdGFyZ2V0IHRoYXQgbWF0Y2hlcyBhIGdpdmVuIFBFcyBwcmVmZXJlbmNl IC0gSEVOQ0UgU0lOR0xFIFRPVUNIIFBPSU5UIQ0KDQpSZWdhcmRzDQoNClZpbm9kIEpvc2VwaA0K U2VudCBmcm9tIG15IEJsYWNrYmVycnkgDQpQcm9mZXNzaW9uYWwgU2VydmljZXMgLSBTZXJ2aWNl IFByb3ZpZGVyIEV1cm9wZSwgVUsgJiBJcmVsYW5kDQpKdW5pcGVyIE5ldHdvcmtzLCBJbmMuIA0K KzQ0IDc1MDAgODM1IDg3Ng0KRTogdmpvc2VwaEBqdW5pcGVyLm5ldA0KIA0KDQoNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogVmlub2QgSm9zZXBoDQpUbzogcmFzenVrQGNp c2NvLmNvbSA8cmFzenVrQGNpc2NvLmNvbT47IEFtaXQgS2hvcGthciA8QW1pdC5LaG9wa2FyQHNu cy5ic2t5Yi5jb20+DQpDYzogaUx5YSA8aWx5YUBub2J1bHVzLmNvbT47IGlkckBpZXRmLm9yZyA8 aWRyQGlldGYub3JnPjsgTGF1cmVudCBMYXZhbGxlZSA8TGF1cmVudC5MYXZhbGxlZUBzbnMuYnNr eWIuY29tPg0KU2VudDogVHVlIEp1biAwNyAyMjozMjowMyAyMDExDQpTdWJqZWN0OiBSRTogW0lk cl0gbW9yZSBvbiBkcmFmdC12aW5vZC1sYXZhbGxlZS1iZ3Atb3B0aW1hbC1yb3V0ZS1yZWZsZWN0 aW9uDQoNClJvYmVydCwNCg0KVGhlcmUgaGFzIGJlZW4gc29tZSBhbW91bnQgb2YgY29uZnVzaW9u IGluIHJlZ2FyZCB0byBCR1Agc3BlYWtlcnMgd2lsbCBoYW5kbGUgdHJhZmZpYyBpbiB0aGUgZXZl bnQgb2YgcHJlZml4ZXMgbm90IGJlaW5nIGF2YWlsYWJsZSBvbiBBU0JScyB0aGF0IG1hdGNoIHRo ZSBSVCBpbnRlcmVzdCBmcm9tIGEgUEVzIHBlcnNwZWN0aXZlLiBMZXQgbWUgY2xhcmlmeSB0aGlz IGhlcmU6DQoNCi0+IExldCB1cyBhc3N1bWUgdGhhdCB0aGVyZSBhcmUgMTAgQVNCUnMgaW4gYSBu ZXR3b3JrIHdpdGggdHdvIFJScyAoUlIxIGFuZCBSUjIpIGFuZCBlYWNoIEFTQlIgaGFzIGFuIFJU IGZvciBpdHMgcHJlZml4ZXMsIGFuZCBQRTEgaGFzIGV4cHJlc3NlZCBpbnRlcmVzdCBpbiB0d28g UlRzIC0gbGV0cyBzYXkgIkEiIGFuZCAiQiIodHdvIEFTQlJzKS4gVGhlIFJSIHdvdWxkIGFubm91 bmNlIHByZWZpeGVzIGZvciB0aGVzZSB0d28gQVNCUnMgb25seSB0byB0aGUgUEUsIHRoZXJlZm9y ZSBpbiB0aGUgZXZlbnQgb2YgcHJlZml4ZXMgbm90IGJlaW5nIGF2YWlsYWJsZSBhdCB0aGVzZSB0 d28gQVNCUnMgLSB0cmFmZmljIG1heSBiZSBibGFja2hvbGVkIGV2ZW4gdGhvdWdoIHRoZXJlIGFy ZSA4IG90aGVyIEFTQlJzIGF2YWlsYWJsZS4gVGhlIGRyYWZ0IGNsZWFybHkgbWVudGlvbnMgdGhh dCBlYWNoIFJSIGNhbiBiZSBhbGxvdHRlZCBhbiBSUiBzcGVjaWZpYyBSVC4gU28gbGV0cyBzYXkg UlIxIGhhcyBhbiBSVCBvZiBYIGFuZCBSUjIgaGFzIFkuIFRoZSBQRTEgY2FuIGFubm91bmNlIGlu dGVyZXN0IGluIFJUICJYIiBhbmQgUlQgIlkiIGluIGFkZGl0aW9uIHRvICJBIiBhbmQgIkIiLiBU aGlzIGlzIGEgY29tbW9uIGRlcGxveW1lbnQgd2hlcmUsIFJSMSBhbmQgUlIyIHdpbGwgYm90aCBh bm5vdW5jZSBwcmVmaXhlcyB0aGF0IG1hdGNoICJBIiBhbmQgIkIiIHBsdXMgdGhlIGJlc3QgcGF0 aCBmb3IgYWxsIHByZWZpeGVzIHRoYXQgaXQgaXMgYXdhcmUgb2YgKFByZWZpeGVzIHdpdGggUlQg ZXh0ZW5kZWQgY29tbXVuaXRpZXMgYW5kIHByZWZpeGVzIHRoYXQgbWF5IGJlIGFubm91bmNlZCB3 aXRob3V0IFJUIGV4dGVuZGVkIGNvbW11bml0eSkuIFRoaXMgd2lsbCBlbnN1cmUgdGhhdCBQRTEg cmVjZWl2ZXMgMiBhZGRpdGlvbmFsIHBhdGhzIGZyb20gUlIxIGFuZCBSUjIgd2hpY2ggY2FuIGJl IHVzZWQgYXMgYmFja3VwIGluIHRoZSBldmVudCBvZiBwcmVmaXhlcyBub3QgYmVpbmcgYXZhaWxh YmxlIGZyb20gUlQgIkEiIGFuZCAiQiIuIFRoaXMgd2lsbCBlbnN1cmUgdGhhdCB0cmFmZmljIHdp bGwgbmV2ZXIgYmUgYmxhY2staG9sZWQgYXQgYWxsICh1bnRpbCB2aWFibGUgcGF0aHMgZXhpc3Qp Lg0KDQotPiBXaGV0aGVyIGEgbmV0d29yayBlbnRpdHkgb3IgbG9jYWwgaXMgYSBtYXR0ZXIgb2Yg aG93IG11Y2ggYWRtaW5pc3RyYXRpdmUgb3ZlcmhlYWQgdnMuIGZsZXhpYmlsaXR5IGNhbiBiZSBh Y2hpZXZlZC4gSW4gdGhlIGNhc2Ugb2YgdGhlIE5IIGRyYWZ0LCBlYWNoIFBFIG5lZWRzIHRvIGJl IGNvbmZpZ3VyZWQgd2l0aCBhbiBhZG1pbmlzdHJhdGl2ZSBkaXN0YW5jZSB0byBlYWNoIEFTQlIg LSBpZiB3ZSBuZWVkIHRvIGFjaGlldmUgc29tZXRoaW5nIHNpbWlsYXIgdG8gd2hhdCBjYW4gYmUg YWNoaWV2ZWQgYnkgdXNpbmcgUlRzLiBUaGlzIGNhbiBiZSBjb21wbGV4LCBzaW5jZSB3ZSB3b3Vs ZCBlbmQgdXAgY2FsY3VsYXRpbmcgZWFjaCBwYWlyIChQRS1BU0JSKSBpbiBhZGRpdGlvbiB0byB0 cmFmZmljIGZsb3dzIG5lZWRlZCB0byBwdXQgaW4gdmFsdWVzLiBPbiB0aGUgY29udHJhcnkgdXNl IG9mIFJUcyBpcyBub3RoaW5nIG5ldyBmb3Igb3BlcmF0b3JzLiBVc2luZyBhcHByb3ByaWF0ZSBS VHMgd291bGQgYmUgdGhlIG9ubHkgc3RlcCBpbnZvbHZlZCBpbiByZWNlaXZpbmcgQVNCUiBwYXRo cy4gQWRkaXRpb24gb2YgbmV3IHBhdGhzLCBtZWFucyAtIGp1c3QgYWRkaW5nIGFub3RoZXIgUlQg aW50ZXJlc3Qgb3IgcmVtb3ZpbmcgaXQgZXRjIGFuZCBkb2VzIG5vdCBpbnZvbHZlIHJlLWVuZ2lu ZWVyaW5nIG1ldHJpY3MuIA0KDQotPiBSVCB1c2VzIGV4aXN0aW5nIEJHUCBtYWNoaW5lcnksIHRo ZXJlZm9yZSBhbiBvcGVyYXRvciBkb2VzIG5vdCBuZWVkIHRvIHdvcnJ5IGFib3V0IHRoZSBzdXBw b3J0IG9mIGEgbmV3IGNhcGFiaWxpdHkuIA0KDQotPiBUaGlzIHNvbHV0aW9uIHByb3Bvc2VzIGEg c2NoZW1lIG9mIGFubm91bmNpbmcgYWZmaW5pdGllcywgZXZlbiBpbiB0aGUgY2FzZSBvZiBBREQt UEFUSCBub3QgYmVpbmcgc3VwcG9ydGVkIG9uIFBFcyAtIHdoaWNoIGlzIGFuIGFkdmFudGFnZS4g U28gYSBQRSBjYW4ganVzdCBpbmRpY2F0ZSBhbiBSVCB0aGF0IG1hdGNoZXMgYW4gQVNCUiB0aGF0 IGlzIGNsb3Nlc3Qgb3IgYWRtaW5pc3RyYXRpdmVseSBwcmVmZXJyZWQgYW5kIHN0aWxsIGdldCB0 aGF0IHBhdGggYW5ub3VuY2VkIGJ5IHRoZSBSUi4gSW4gYWRkaXRpb24gUlIgc3BlY2lmaWMgUlRz IChhcyBtZW50aW9uZWQgYWJvdmUpIGNhbiBwcm92aWRlIGJhY2t1cCBpbiB0aGUgZXZlbnQgb2Yg dGhlIHByZWZlcnJlZCBBU0JSIGxvc2luZyBwcmVmaXhlcyBvciBnb2luZyBvZmZsaW5lLg0KDQot PiBEZS1jb3VwbGluZyB0aGUgUlIgZnJvbSBwYXRoIHNlbGVjdGlvbiB0aHJvdWdoIGludGVsbGln ZW50IHJlcXVlc3RzIHRocm91Z2ggYWZmaW5pdGllcyBjYW4gY2VydGFpbmx5IHJlZHVjZSB0aGUg b3ZlcmhlYWQgb24gdGhlIFJSICsgdGhlIGNodXJuIGNhdXNlZCBvbiB0aGUgUlIgZHVlIHRvIFNQ RiBydW5zLg0KDQotPiBJdCBpcyB0aGUgZWFzZSBvZiBhZG9wdGlvbiAtIHNpbmNlIFJUIGhhcyBi ZWVuIGRlcGxveWVkIGZvciBhIHdoaWxlIG5vdyB3aGljaCBtYWtlcyBpdCBzaW1wbGVyLg0KDQpB IHVwZGF0ZWQgdmVyc2lvbiAoMDEpIG9mIHRoZSBkcmFmdCBlbGFib3JhdGluZyBzb21lIG9mIHRo ZXNlIHNjZW5hcmlvcyBpbiBsYXJnZSBkZXRhaWwgd2lsbCBiZSByZWxlYXNlZCBzaG9ydGx5Lg0K DQpSZWdhcmRzDQoNClZpbm9kIEpvc2VwaA0KUHJvZmVzc2lvbmFsIFNlcnZpY2VzIOKAkyBTZXJ2 aWNlIFByb3ZpZGVyIEVNRUENCkp1bmlwZXIgTmV0d29ya3PCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoA0K TTogKzQ0ICgwKSA3NTAwIDgzNSA4NzYNCkU6wqB2am9zZXBoQGp1bmlwZXIubmV0DQrCoA0KDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvYmVydCBSYXN6dWsgW21haWx0 bzpyYXN6dWtAY2lzY28uY29tXSANClNlbnQ6IDA3IEp1bmUgMjAxMSAxNzoyNQ0KVG86IEFtaXQg S2hvcGthcg0KQ2M6IGlMeWE7IFZpbm9kIEpvc2VwaDsgaWRyQGlldGYub3JnOyBMYXVyZW50IExh dmFsbGVlDQpTdWJqZWN0OiBSZTogW0lkcl0gbW9yZSBvbiBkcmFmdC12aW5vZC1sYXZhbGxlZS1i Z3Atb3B0aW1hbC1yb3V0ZS1yZWZsZWN0aW9uDQoNCkhpIEFtaXQsDQoNCj4gMy4gdGhlcmUgYXJl IHR3byBhcHByb2FjaGVzIHRvIHJlc29sdmUgdGhpcyBhLiBsZXQgdGhlIHJvdXRlDQo+IHJlZmxl Y3RvciBtYWtlIGEgZGVjaXNpb24gZm9yIGV2ZXJ5IFBFIGJhc2VkIG9uIHNvbWUgY3JpdGVyaWEg KElHUA0KPiBtZXRyaWMgaW4geW91ciBkcmFmdCkgYi4gdGFrZSB0aGUgUlIgb3V0IG9mIHRoZSBy b3V0ZSBzZWxlY3Rpb24NCj4gcHJvY2VzcyAob25lIG9mIHRoZSBtYWluIHJlYXNvbnMgZm9yIGV4 aXN0ZW5jZSBvZiBBREQtUEFUSCkgYnV0IGluIGENCj4gc2NhbGFibGUgbWFubmVyDQoNClNpbmNl IENoaW50YW4gaXMgYWxzbyBhcHBhcmVudGx5IGluIHRoZSBzYW1lIGFzc3VtcHRpb24gbGV0IG1l IHJlaXRlcmF0ZSANCnRoYXQgYmFzZSBPUlIgSURSIFdHIGRyYWZ0IGNhbiB1c2UgSUdQIG1ldHJp YyBvciBhbmd1bGFyIGRpc3RhbmNlIA0KYXBwcm94aW1hdGlvbiB0ZWNobmlxdWVzIHRvIHNlbGVj dCBvcHRpbWFsIHBhdGhzLg0KDQpOb3cgaWYgb3B0aW1hbCBmb3IgYW4gb3BlcmF0b3IgbWVhbnMg dG8gdXNlIGhpcyBvdGhlciBjcml0ZXJpYSB0aGUgDQpOSC1TQUZJIGRyYWZ0IElseWEgYW5kIEkg d3JvdGUgY29tZXMgaGFuZHkgYXMgIm1ldHJpYyIgd2hpY2ggUEUgcmVwbGllcyANCnRvIFJSIGlz IGp1c3QgYSBudW1iZXIuIFllcyBpdCBjb3VsZCBiZSByZWxhdGVkIHRvIElHUCB2aWV3IG9mIFBF IHRvIA0Kc3VjaCBuZXh0IGhvcCwgYnV0IGVxdWFsbHkgd2VsbCBpdCBjYW4gYmUgcmVsYXRlZCB0 byBvcGVyYXRvcidzIGxvY2FsIA0KcG9saWN5Lg0KDQpTdWNoIGxvY2FsIHBvbGljeSBuZWVkcyB0 byBiZSBjb25maWd1cmVkIGFuZCBleHByZXNzZWQgc29tZWhvdy4gWW91ciANCmRyYWZ0IHJlY29t bWVuZHMgY29uZmlndXJpbmcgUlQgdG8gbWF0Y2ggd2hhdCBzYWlkIEFTQlJzIHdvdWxkIHVzZSBp biANCnJvdXRlIG1hcmtpbmcgd2hhdCBjbGVhcmx5IGlzIG1vcmUgY29tcGxleCB0aGVuIGFsbG9j YXRpbmcgbG9jYWwgdmFsdWUgDQphcyBsb2NhbCB2YWx1ZSBkb2VzIG5vdCByZXF1aXJlIGEgY29y cmVsYXRpb24gd2l0aCBhbnkgb3RoZXIgbmV0d29yayANCmVudGl0eS4gVGhhdCBzZWVtcyB0byBi ZSBhIGRpZmZlcmVuY2UgeW91IGFyZSBub3Qgc2VlaW5nLg0KDQpUaGUgYm90dG9tIGxpbmUgSURS IFdHIGRyYWZ0ICsgZHJhZnQtdmFybGFzaGtpbi1iZ3AtbmgtY29zdCBhbHJlYWR5IA0KYWRkcmVz cyBhbGwgcG9zc2libGUgc2NlbmFyaW9zIHdoaWNoIHlvdSBtYXkgbmVlZCBieSB1c2luZyB5b3Vy IGRyYWZ0Lg0KDQpJZiB0aGVyZSBpcyBzb21ldGhpbmcgaW4geW91ciBkcmFmdCB3aGljaCB0aGUg YWJvdmUgc2V0IGlzIG1pc3NpbmcgYW5kIA0Kd2hpY2ggYnkgdXNpbmcgdGhlIGFib3ZlIHR3byBk cmFmdHMgY291bGQgbm90IGJlIGFjY29tcGxpc2hlZCBwbGVhc2UgDQpjbGVhcmx5IGV4cGxhaW4u DQoNCk1hbnkgdGh4LA0KUi4NCg== From raszuk@cisco.com Wed Jun 8 00:09:12 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0C511E80B3 for ; Wed, 8 Jun 2011 00:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.083 X-Spam-Level: X-Spam-Status: No, score=-10.083 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYWCpFiuPl7p for ; Wed, 8 Jun 2011 00:09:11 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEED11E80A2 for ; Wed, 8 Jun 2011 00:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=7272; q=dns/txt; s=iport; t=1307516951; x=1308726551; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ftO0LhyVPIkQgE56FqwcuaDOHpiCEizppPo3aaO+94M=; b=jmUpg+QfS0bUFB2Hg0Bu7HKRbLBByQsQzxLaGDYRwsSqbCBCIzpWIcfn Gy+Pjssjsp+WLJdFMbF4FR7++mak/0GAj8jFIZx429NC2qs0JdHUU8gi5 3c+qihmGV9CIBJVnqJOkP75qJbeNuR5RaduN3s6H6YKJOK4m5z9UlO30o Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADgf702rRDoJ/2dsb2JhbABThEqhYHeIcaFkgwAPAYoAkHKBK4NugQoEkRuETYsA X-IronPort-AV: E=Sophos;i="4.65,337,1304294400"; d="scan'208";a="332453348" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2011 07:09:11 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p58798a4016981; Wed, 8 Jun 2011 07:09:08 GMT Message-ID: <4DEF2027.5080605@cisco.com> Date: Wed, 08 Jun 2011 09:09:27 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:09:12 -0000 Vinod, > PEs only signal interest via RT constrain and do not need to attach > RTs to their local prefixes. If PEs are signaling their route preference interest via RT constrain I would assume they would have to be configured with those RTs ahead of time as well. If not how would the PE know what to signal in RT constrain towards the RRs ? Thx, R. > Further elaborating on the amount of configurations required in this > draft vs the other proposals. > > Only ASBRs need to be configured with Route targets when advertised > to the RRs, and I am sure ASBRs are much fewer in number to PEs. The > PEs only signal interest via RT constrain and do not need to attach > RTs to their local prefixes. The reason: In most cases PE announced > customer prefixes can be controlled using standard BGP methods, if > these PE announced prefixes are not needed on an ASBR for some > special reason. > > On the contrary, the other solution needs every PE to ASBR pair > mapped with an administrative cost in cases where the IGP is not > preferred for use. If you have situations where each PE or groups of > PEs have diverse outbound traffic flow requirements, you would end up > having to manually setup potentially huge number of PE+ASBR pairs. In > the event of a new ASBR introduced in the network, all PEs that need > to use this ASBR as a primary exit point will need reconfiguration. > Using RT, only the ASBR will need to be configured to advertise its > paths with an additional Route target that matches a given PEs > preference - HENCE SINGLE TOUCH POINT! > > Regards > > Vinod Joseph Sent from my Blackberry Professional Services - Service > Provider Europe, UK& Ireland Juniper Networks, Inc. +44 7500 835 > 876 E: vjoseph@juniper.net > > > > > ----- Original Message ----- From: Vinod Joseph To: > raszuk@cisco.com; Amit > Khopkar Cc: iLya; > idr@ietf.org; Laurent > Lavallee Sent: Tue Jun 07 22:32:03 > 2011 Subject: RE: [Idr] more on > draft-vinod-lavallee-bgp-optimal-route-reflection > > Robert, > > There has been some amount of confusion in regard to BGP speakers > will handle traffic in the event of prefixes not being available on > ASBRs that match the RT interest from a PEs perspective. Let me > clarify this here: > > -> Let us assume that there are 10 ASBRs in a network with two RRs > (RR1 and RR2) and each ASBR has an RT for its prefixes, and PE1 has > expressed interest in two RTs - lets say "A" and "B"(two ASBRs). The > RR would announce prefixes for these two ASBRs only to the PE, > therefore in the event of prefixes not being available at these two > ASBRs - traffic may be blackholed even though there are 8 other ASBRs > available. The draft clearly mentions that each RR can be allotted an > RR specific RT. So lets say RR1 has an RT of X and RR2 has Y. The PE1 > can announce interest in RT "X" and RT "Y" in addition to "A" and > "B". This is a common deployment where, RR1 and RR2 will both > announce prefixes that match "A" and "B" plus the best path for all > prefixes that it is aware of (Prefixes with RT extended communities > and prefixes that may be announced without RT extended community). > This will ensure that PE1 receives 2 additional paths from RR1 and > RR2 which can be used as backup in the event of prefixes not being > available from RT "A" and "B". This will ensure that traffic will > never be black-holed at all (until viable paths exist). > > -> Whether a network entity or local is a matter of how much > administrative overhead vs. flexibility can be achieved. In the case > of the NH draft, each PE needs to be configured with an > administrative distance to each ASBR - if we need to achieve > something similar to what can be achieved by using RTs. This can be > complex, since we would end up calculating each pair (PE-ASBR) in > addition to traffic flows needed to put in values. On the contrary > use of RTs is nothing new for operators. Using appropriate RTs would > be the only step involved in receiving ASBR paths. Addition of new > paths, means - just adding another RT interest or removing it etc and > does not involve re-engineering metrics. > > -> RT uses existing BGP machinery, therefore an operator does not > need to worry about the support of a new capability. > > -> This solution proposes a scheme of announcing affinities, even in > the case of ADD-PATH not being supported on PEs - which is an > advantage. So a PE can just indicate an RT that matches an ASBR that > is closest or administratively preferred and still get that path > announced by the RR. In addition RR specific RTs (as mentioned above) > can provide backup in the event of the preferred ASBR losing prefixes > or going offline. > > -> De-coupling the RR from path selection through intelligent > requests through affinities can certainly reduce the overhead on the > RR + the churn caused on the RR due to SPF runs. > > -> It is the ease of adoption - since RT has been deployed for a > while now which makes it simpler. > > A updated version (01) of the draft elaborating some of these > scenarios in large detail will be released shortly. > > Regards > > Vinod Joseph Professional Services – Service Provider EMEA Juniper > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net > > > > > -----Original Message----- From: Robert Raszuk > [mailto:raszuk@cisco.com] Sent: 07 June 2011 17:25 To: Amit Khopkar > Cc: iLya; Vinod Joseph; idr@ietf.org; Laurent Lavallee Subject: Re: > [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection > > Hi Amit, > >> 3. there are two approaches to resolve this a. let the route >> reflector make a decision for every PE based on some criteria (IGP >> metric in your draft) b. take the RR out of the route selection >> process (one of the main reasons for existence of ADD-PATH) but in >> a scalable manner > > Since Chintan is also apparently in the same assumption let me > reiterate that base ORR IDR WG draft can use IGP metric or angular > distance approximation techniques to select optimal paths. > > Now if optimal for an operator means to use his other criteria the > NH-SAFI draft Ilya and I wrote comes handy as "metric" which PE > replies to RR is just a number. Yes it could be related to IGP view > of PE to such next hop, but equally well it can be related to > operator's local policy. > > Such local policy needs to be configured and expressed somehow. Your > draft recommends configuring RT to match what said ASBRs would use > in route marking what clearly is more complex then allocating local > value as local value does not require a correlation with any other > network entity. That seems to be a difference you are not seeing. > > The bottom line IDR WG draft + draft-varlashkin-bgp-nh-cost already > address all possible scenarios which you may need by using your > draft. > > If there is something in your draft which the above set is missing > and which by using the above two drafts could not be accomplished > please clearly explain. > > Many thx, R. From stephane.litkowski@orange-ftgroup.com Wed Jun 8 05:25:19 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1B621F8481 for ; Wed, 8 Jun 2011 05:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8chqCW+W1z5g for ; Wed, 8 Jun 2011 05:25:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DC7BB21F8476 for ; Wed, 8 Jun 2011 05:25:17 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 1E6912DC3C4; Wed, 8 Jun 2011 14:25:16 +0200 (CEST) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 03030238055; Wed, 8 Jun 2011 14:25:16 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jun 2011 14:25:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 14:25:13 +0200 Message-ID: <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95AAB7/C6A= References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1><4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> From: To: X-OriginalArrivalTime: 08 Jun 2011 12:25:15.0962 (UTC) FILETIME=[1F4391A0:01CC25D7] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.8.102714 Cc: idr@ietf.org Subject: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 12:25:19 -0000 Hi Vinod, Some comments your the draft, I followed quickly all the discussions on the= subject on this mailing list but I have some questions more oriented on ho= w your system is explained in your document. I understand globally your idea, and I agree with Robert on the fact that y= our draft is not proposing an optimal route-reflection but more an "ingress= preference-based" route-reflection. I understand your explanation about wh= at is behind the word "optimal" but generally optimal is always shortest IG= P :) otherwise this is more preference based routing. To go more deeper in your text, in the =A75.2, you are talking about "The o= bjective here is to ensure that the "best path" based on the shortest IGP m= etric from each PE to an ASBR is announced by the RR.". I don't really agre= e on that, because your ingress router is able to choose the paths that wil= l be given to him by the RR using the RT mechanism. So it could , or could= not be the shortest IGP metric path (the operator is choosing by himself).= So If my understanding of your system is good, imo a rephrasing could be n= ecessary to explain the exact goal/possibilities of your system. I agree th= at you can achieve hot potatoe routing with your system, but it is just a s= ubcase of a more global approach. Then you propose to use RT Constraint for IPv4 AFI/SAFI, as mentionned by R= obert, today RTC is not done per AFI/SAFI, so you will have to deal with th= is and not interfer with current VPNs deployed (especially if you are mixin= g IPv4/VPNv4 on RRs), it's not blocking but operator must be aware of this = when deploying your solution. Moreover you are not using basic RTC like we do for VPNv4, because you need= to modify the RR behavior to be able to compute "best path" per peer or pe= r peer-group : this is not done today with current RTC. RTC in VPNv4 is wor= king fine because of unicity of prefixes ensured by RD, but this is not the= case for IPv4. You need to modify the way best path is computed. RTC, it's= just putting an ORF ;) but without modifying best path computation, we are= just filtering the RIB-OUT. We can guess this in your document, but imho t= his is not clearly explained. So what is your approach here : - 1) using ADD-PATH "export all" in addition to RTC, so all routes are put= ted in RIB-OUT then filtered towards PE by the RR based on the RT-ORF ? - 2) modify the best path mechanism, create a per peer/peer-group path eli= gible group (based on RTC infos), then do ADDPATH to export all paths or so= me paths inside this group ? - 3) Something else ? Another point, RTC is a complex BGP machinery, new AFI/SAFI, new way to pro= pagate this AFI/SAFI ... But here in fact you just need a point to point me= chanism, why not using RT based ORF, or simply a BGP standard community bas= ed ORF ? If your ASBRs are marking routes using a special CT (normal 32bits= community), PE can choose this ASBR by just signalling a CT based ORF to t= he RR (in combination with ADD-PATH) ?. So there is nothing new to implemen= t (except CT based ORF, but ORF idea is globally already existing). Then you have to take into account that your ingress router need to receive= routes other than ASBR routes, so your mechanism must not prevent that. If= you are using RTC, you will receive only routes matching your RT, potentia= lly "internal" routes will not be received anymore if you don't marked them= with an RT imported by all your routers. Let me know your thought, Best Regards, Stephane =20 ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From vjoseph@juniper.net Wed Jun 8 06:01:31 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BED711E808B for ; Wed, 8 Jun 2011 06:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYyZFe82-+iY for ; Wed, 8 Jun 2011 06:01:30 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id D554411E8095 for ; Wed, 8 Jun 2011 06:01:21 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTe9yobrESIYNfdjoBDN2K3h3eeMujtZ/@postini.com; Wed, 08 Jun 2011 06:01:30 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 06:01:03 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 14:01:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 14:01:19 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95AAB7/C6AAAQPyYA== References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1><4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> From: Vinod Joseph To: X-OriginalArrivalTime: 08 Jun 2011 13:01:01.0891 (UTC) FILETIME=[1E565930:01CC25DC] Cc: idr@ietf.org, "Thareja, Gaurav" , Amit Khopkar , Chintan.Shah@colt.net, laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:01:31 -0000 Hi Stephane, Comments inline as Vinod# Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com]=20 Sent: 08 June 2011 13:25 To: Vinod Joseph Cc: idr@ietf.org Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Hi Vinod, Some comments your the draft, I followed quickly all the discussions on = the subject on this mailing list but I have some questions more oriented = on how your system is explained in your document. I understand globally your idea, and I agree with Robert on the fact = that your draft is not proposing an optimal route-reflection but more an = "ingress preference-based" route-reflection. I understand your = explanation about what is behind the word "optimal" but generally = optimal is always shortest IGP :) otherwise this is more preference = based routing. Vinod# I am open to suggestions as you mentioned to changed the word = "optimal" to something else - if that helps. Carriers do define optimal = as being the closest IGP next-hop and this scheme does permit that to be = achieved using preferences indicated via RT Constrain. As you mention, = it moves one step further in permitting preference based routing (if you = like). Do keep in mind that this proposal does use the IGP metric as the = tie breaker in any case. For instance if a BGP speaker indicates a = preference for RT:X, and if RT:X has 4 paths, which get advertised by = the RR to the PE - Then the PE under normal conditions will choose the = NH with the closest IGP metric anyways.=20 To go more deeper in your text, in the =A75.2, you are talking about = "The objective here is to ensure that the "best path" based on the = shortest IGP metric from each PE to an ASBR is announced by the RR.". I = don't really agree on that, because your ingress router is able to = choose the paths that will be given to him by the RR using the RT = mechanism. So it could , or could not be the shortest IGP metric path = (the operator is choosing by himself). So If my understanding of your = system is good, imo a rephrasing could be necessary to explain the exact = goal/possibilities of your system. I agree that you can achieve hot = potatoe routing with your system, but it is just a subcase of a more = global approach. Vinod# Yes. But Like I mentioned the tie breaker when multiple paths are = announced to a PE is the shortest IGP metric. Therefore if the operator = decides that he only wants a set of ASBRs chosen for traffic exit - the = choice within those set of paths will always be the closest ASBR. Then you propose to use RT Constraint for IPv4 AFI/SAFI, as mentionned = by Robert, today RTC is not done per AFI/SAFI, so you will have to deal = with this and not interfer with current VPNs deployed (especially if you = are mixing IPv4/VPNv4 on RRs), it's not blocking but operator must be = aware of this when deploying your solution. Moreover you are not using basic RTC like we do for VPNv4, because you = need to modify the RR behavior to be able to compute "best path" per = peer or per peer-group : this is not done today with current RTC. RTC in = VPNv4 is working fine because of unicity of prefixes ensured by RD, but = this is not the case for IPv4. You need to modify the way best path is = computed. RTC, it's just putting an ORF ;) but without modifying best = path computation, we are just filtering the RIB-OUT. We can guess this = in your document, but imho this is not clearly explained. So what is = your approach here : - 1) using ADD-PATH "export all" in addition to RTC, so all routes are = putted in RIB-OUT then filtered towards PE by the RR based on the RT-ORF = ? - 2) modify the best path mechanism, create a per peer/peer-group path = eligible group (based on RTC infos), then do ADDPATH to export all paths = or some paths inside this group ? - 3) Something else ? Vinod# There is another version of the draft clearly mentioning these = scenarios in detail and I did mention this in email to Robert yesterday. = There is no best path calculation when using RT constrain. The RR just = picks the number of paths that match a given RT and advertise this to = the PE. So there would be no advantage in exporting all paths to the = RIB-OUT and then filtering prefixes/paths based on RT-ORF. The ideal = approach would instead be to create a per peer-group based model where = appropriate RT paths are only announced. The best path calculation is = only performed when an RR specific RT is announced. I had emailed this = yesterday, wherein a PE can signal an RT that is allocated to a given = set of RR(s), and the RR(s) just announce the best path for all prefixes = ir-respective of whether an RT is attached or not.=20 Another point, RTC is a complex BGP machinery, new AFI/SAFI, new way to = propagate this AFI/SAFI ... But here in fact you just need a point to = point mechanism, why not using RT based ORF, or simply a BGP standard = community based ORF ? If your ASBRs are marking routes using a special = CT (normal 32bits community), PE can choose this ASBR by just signalling = a CT based ORF to the RR (in combination with ADD-PATH) ?. So there is = nothing new to implement (except CT based ORF, but ORF idea is globally = already existing). Then you have to take into account that your ingress router need to = receive routes other than ASBR routes, so your mechanism must not = prevent that. If you are using RTC, you will receive only routes = matching your RT, potentially "internal" routes will not be received = anymore if you don't marked them with an RT imported by all your = routers. Vinod# Standard communities are already used for various purposes such = as filtering which customer routes get installed where and so on.... and = we did not want to dilute this by using standard communities for another = whole new purpose. The intent of this proposal is to leverage existing = machinery - RT and RT constrain exists in all code and deployments. We = ensure that the PE router will receive all routes other than routes = matching the RT, and this is done by allotting an RT per RR as I = mentioned in my previous emails. Each PE just needs to signal these RR = specific RTs or an RR specific RT to get the best path for all other = prefixes other than the interested RT alone. Therefore there never be a = situation where a PE will be starved of routing information if ASBRs = that match the RTs signalled via RTC lose visibility to any prefixes. Keep in mind that this proposal can work with existing machinery as well = i.e. if ADD-PATH is yet to be supported on PEs. In the event of PEs not = supporting ADD-PATH, the RR would only send a single path per RT that = gets signalled.=20 Let me know your thought, Best Regards, Stephane =20 *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* From vjoseph@juniper.net Wed Jun 8 06:07:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021C611E80C9 for ; Wed, 8 Jun 2011 06:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.937 X-Spam-Level: X-Spam-Status: No, score=-5.937 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJeY4NgYm8cu for ; Wed, 8 Jun 2011 06:06:58 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2E11E80DA for ; Wed, 8 Jun 2011 06:06:55 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTe9z6T1i7qrb9eQsH93Vrs26B+QYjms4@postini.com; Wed, 08 Jun 2011 06:06:58 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 06:06:06 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 14:06:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 8 Jun 2011 14:06:11 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlqvmsagcC/NJxQLu0F/j7hPDzhAAMTYzQ References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> From: Vinod Joseph To: X-OriginalArrivalTime: 08 Jun 2011 13:06:05.0452 (UTC) FILETIME=[D34614C0:01CC25DC] Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:07:00 -0000 SSB3b3VsZCBsb29rIGF0IHRoaXMgd2F5IFJvYmVydC4gQW4gb3BlcmF0b3IgbWF5IHBsYW4gdG8g YWxsb3QgYSBzZXQgb2YgUlQgdmFsdWVzIGxldHMgc2F5ICgxLTEwKSBmb3IgYSBnaXZlbiBQT1Av UmVnaW9uLiBUaGUgcHJvcG9zYWwgc3BlY2lmaWVzIHRoZSBuZWVkIGZvciB0aGUgaW1wbGVtZW50 YXRpb24gdG8gc3VwcG9ydCBSVCB2YWx1ZXMgYXMgcmFuZ2VzIGFzIHdlbGwuIFNvIGVhY2ggUEUg aW4gYSByZWdpb24gY2FuIGp1c3QgaW5jbHVkZSBhIHJhbmdlIG9mIFJUcywgYW5kIHRoaXMgbWF5 IGluY2x1ZGUgYWxsIG9yIG5lYXIgdG8gY29tcGxldGUgUlQgdmFsdWVzIHRoYXQgbWF5IGJlIGFs bG90dGVkIGluIGEgUE9QLiBTbyB3aGVuIGEgbmV3IEFTQlIgaXMgYWRkZWQsIGFsbCB5b3UgbmVl ZCBpcyB0aGUgQVNCUiB0byBoYXZlIHRoZSBhcHByb3ByaWF0ZSBSVCB1c2VkLiANCg0KSW4gY29u dHJhc3QsIHlvdSB3b3VsZCBuZWVkIHRvIHJlLWVuZ2luZWVyIGVhY2ggUEUgdG8gaGF2ZSBhIG5l dyBtZXRyaWMgKGFkbWluaXN0cmF0aXZlKSB0b3dhcmRzIHRoZSBuZXcgQVNCUi4gU28gaW4gZWZm ZWN0IGV2ZXJ5IFBFIGludGVyZXN0ZWQgaW4gdGhhdCBBU0JSIG5lZWRzIHJlLWNhbGN1bGF0aW9u IChvbiB3aGF0IG1ldHJpYyBpcyB0byBiZSB1c2VkIGFuZCB3aGV0aGVyIHRoaXMgQVNCUiBpcyBn b2luZyB0byBiZSB0aGUgcHJpbWFyeSBwYXRoIG9yIGJhY2t1cCBhbmQgc28gb24pIGFuZCByZS1j b25maWd1cmF0aW9uLiANCg0KUmVnYXJkcw0KDQpWaW5vZCBKb3NlcGgNClByb2Zlc3Npb25hbCBT ZXJ2aWNlcyDigJMgU2VydmljZSBQcm92aWRlciBFdXJvcGUNCkp1bmlwZXIgTmV0d29ya3PCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoA0KTTogKzQ0ICgwKSA3NTAwIDgzNSA4NzYNCkU6wqB2am9zZXBoQGp1 bmlwZXIubmV0DQrCoA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJv YmVydCBSYXN6dWsgW21haWx0bzpyYXN6dWtAY2lzY28uY29tXSANClNlbnQ6IDA4IEp1bmUgMjAx MSAwODowOQ0KVG86IFZpbm9kIEpvc2VwaA0KQ2M6IEFtaXQuS2hvcGthckBzbnMuYnNreWIuY29t OyBpbHlhQG5vYnVsdXMuY29tOyBpZHJAaWV0Zi5vcmc7IExhdXJlbnQuTGF2YWxsZWVAc25zLmJz a3liLmNvbTsgQ2hpbnRhbi5TaGFoQGNvbHQubmV0OyBHYXVyYXYuVGhhcmVqYUBjb2x0Lm5ldA0K U3ViamVjdDogUmU6IFtJZHJdIG1vcmUgb24gZHJhZnQtdmlub2QtbGF2YWxsZWUtYmdwLW9wdGlt YWwtcm91dGUtcmVmbGVjdGlvbg0KDQpWaW5vZCwNCg0KID4gUEVzIG9ubHkgc2lnbmFsIGludGVy ZXN0IHZpYSBSVCBjb25zdHJhaW4gYW5kIGRvIG5vdCBuZWVkIHRvIGF0dGFjaA0KID4gUlRzIHRv IHRoZWlyIGxvY2FsIHByZWZpeGVzLg0KDQpJZiBQRXMgYXJlIHNpZ25hbGluZyB0aGVpciByb3V0 ZSBwcmVmZXJlbmNlIGludGVyZXN0IHZpYSBSVCBjb25zdHJhaW4gSSANCndvdWxkIGFzc3VtZSB0 aGV5IHdvdWxkIGhhdmUgdG8gYmUgY29uZmlndXJlZCB3aXRoIHRob3NlIFJUcyBhaGVhZCBvZiAN CnRpbWUgYXMgd2VsbC4NCg0KSWYgbm90IGhvdyB3b3VsZCB0aGUgUEUga25vdyB3aGF0IHRvIHNp Z25hbCBpbiBSVCBjb25zdHJhaW4gdG93YXJkcyB0aGUgDQpSUnMgPw0KDQpUaHgsDQpSLg0KDQoN Cg0KPiBGdXJ0aGVyIGVsYWJvcmF0aW5nIG9uIHRoZSBhbW91bnQgb2YgY29uZmlndXJhdGlvbnMg cmVxdWlyZWQgaW4gdGhpcw0KPiBkcmFmdCB2cyB0aGUgb3RoZXIgcHJvcG9zYWxzLg0KPg0KPiBP bmx5IEFTQlJzIG5lZWQgdG8gYmUgY29uZmlndXJlZCB3aXRoIFJvdXRlIHRhcmdldHMgd2hlbiBh ZHZlcnRpc2VkDQo+IHRvIHRoZSBSUnMsIGFuZCBJIGFtIHN1cmUgQVNCUnMgYXJlIG11Y2ggZmV3 ZXIgaW4gbnVtYmVyIHRvIFBFcy4gVGhlDQo+IFBFcyBvbmx5IHNpZ25hbCBpbnRlcmVzdCB2aWEg UlQgY29uc3RyYWluIGFuZCBkbyBub3QgbmVlZCB0byBhdHRhY2gNCj4gUlRzIHRvIHRoZWlyIGxv Y2FsIHByZWZpeGVzLiBUaGUgcmVhc29uOiBJbiBtb3N0IGNhc2VzIFBFIGFubm91bmNlZA0KPiBj dXN0b21lciBwcmVmaXhlcyBjYW4gYmUgY29udHJvbGxlZCB1c2luZyBzdGFuZGFyZCBCR1AgbWV0 aG9kcywgaWYNCj4gdGhlc2UgUEUgYW5ub3VuY2VkIHByZWZpeGVzIGFyZSBub3QgbmVlZGVkIG9u IGFuIEFTQlIgZm9yIHNvbWUNCj4gc3BlY2lhbCByZWFzb24uDQo+DQo+IE9uIHRoZSBjb250cmFy eSwgdGhlIG90aGVyIHNvbHV0aW9uIG5lZWRzIGV2ZXJ5IFBFIHRvIEFTQlIgcGFpcg0KPiBtYXBw ZWQgd2l0aCBhbiBhZG1pbmlzdHJhdGl2ZSBjb3N0IGluIGNhc2VzIHdoZXJlIHRoZSBJR1AgaXMg bm90DQo+IHByZWZlcnJlZCBmb3IgdXNlLiBJZiB5b3UgaGF2ZSBzaXR1YXRpb25zIHdoZXJlIGVh Y2ggUEUgb3IgZ3JvdXBzIG9mDQo+IFBFcyBoYXZlIGRpdmVyc2Ugb3V0Ym91bmQgdHJhZmZpYyBm bG93IHJlcXVpcmVtZW50cywgeW91IHdvdWxkIGVuZCB1cA0KPiBoYXZpbmcgdG8gbWFudWFsbHkg c2V0dXAgcG90ZW50aWFsbHkgaHVnZSBudW1iZXIgb2YgUEUrQVNCUiBwYWlycy4gSW4NCj4gdGhl IGV2ZW50IG9mIGEgbmV3IEFTQlIgaW50cm9kdWNlZCBpbiB0aGUgbmV0d29yaywgYWxsIFBFcyB0 aGF0IG5lZWQNCj4gdG8gdXNlIHRoaXMgQVNCUiBhcyBhIHByaW1hcnkgZXhpdCBwb2ludCB3aWxs IG5lZWQgcmVjb25maWd1cmF0aW9uLg0KPiBVc2luZyBSVCwgb25seSB0aGUgQVNCUiB3aWxsIG5l ZWQgdG8gYmUgY29uZmlndXJlZCB0byBhZHZlcnRpc2UgaXRzDQo+IHBhdGhzIHdpdGggYW4gYWRk aXRpb25hbCBSb3V0ZSB0YXJnZXQgdGhhdCBtYXRjaGVzIGEgZ2l2ZW4gUEVzDQo+IHByZWZlcmVu Y2UgLSBIRU5DRSBTSU5HTEUgVE9VQ0ggUE9JTlQhDQo+DQo+IFJlZ2FyZHMNCj4NCj4gVmlub2Qg Sm9zZXBoIFNlbnQgZnJvbSBteSBCbGFja2JlcnJ5IFByb2Zlc3Npb25hbCBTZXJ2aWNlcyAtIFNl cnZpY2UNCj4gUHJvdmlkZXIgRXVyb3BlLCBVSyYgIElyZWxhbmQgSnVuaXBlciBOZXR3b3Jrcywg SW5jLiArNDQgNzUwMCA4MzUNCj4gODc2IEU6IHZqb3NlcGhAanVuaXBlci5uZXQNCj4NCj4NCj4N Cj4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSBGcm9tOiBWaW5vZCBKb3NlcGggVG86 DQo+IHJhc3p1a0BjaXNjby5jb208cmFzenVrQGNpc2NvLmNvbT47IEFtaXQNCj4gS2hvcGthcjxB bWl0Lktob3BrYXJAc25zLmJza3liLmNvbT4gQ2M6IGlMeWE8aWx5YUBub2J1bHVzLmNvbT47DQo+ IGlkckBpZXRmLm9yZzxpZHJAaWV0Zi5vcmc+OyBMYXVyZW50DQo+IExhdmFsbGVlPExhdXJlbnQu TGF2YWxsZWVAc25zLmJza3liLmNvbT4gU2VudDogVHVlIEp1biAwNyAyMjozMjowMw0KPiAyMDEx IFN1YmplY3Q6IFJFOiBbSWRyXSBtb3JlIG9uDQo+IGRyYWZ0LXZpbm9kLWxhdmFsbGVlLWJncC1v cHRpbWFsLXJvdXRlLXJlZmxlY3Rpb24NCj4NCj4gUm9iZXJ0LA0KPg0KPiBUaGVyZSBoYXMgYmVl biBzb21lIGFtb3VudCBvZiBjb25mdXNpb24gaW4gcmVnYXJkIHRvIEJHUCBzcGVha2Vycw0KPiB3 aWxsIGhhbmRsZSB0cmFmZmljIGluIHRoZSBldmVudCBvZiBwcmVmaXhlcyBub3QgYmVpbmcgYXZh aWxhYmxlIG9uDQo+IEFTQlJzIHRoYXQgbWF0Y2ggdGhlIFJUIGludGVyZXN0IGZyb20gYSBQRXMg cGVyc3BlY3RpdmUuIExldCBtZQ0KPiBjbGFyaWZ5IHRoaXMgaGVyZToNCj4NCj4gLT4gIExldCB1 cyBhc3N1bWUgdGhhdCB0aGVyZSBhcmUgMTAgQVNCUnMgaW4gYSBuZXR3b3JrIHdpdGggdHdvIFJS cw0KPiAoUlIxIGFuZCBSUjIpIGFuZCBlYWNoIEFTQlIgaGFzIGFuIFJUIGZvciBpdHMgcHJlZml4 ZXMsIGFuZCBQRTEgaGFzDQo+IGV4cHJlc3NlZCBpbnRlcmVzdCBpbiB0d28gUlRzIC0gbGV0cyBz YXkgIkEiIGFuZCAiQiIodHdvIEFTQlJzKS4gVGhlDQo+IFJSIHdvdWxkIGFubm91bmNlIHByZWZp eGVzIGZvciB0aGVzZSB0d28gQVNCUnMgb25seSB0byB0aGUgUEUsDQo+IHRoZXJlZm9yZSBpbiB0 aGUgZXZlbnQgb2YgcHJlZml4ZXMgbm90IGJlaW5nIGF2YWlsYWJsZSBhdCB0aGVzZSB0d28NCj4g QVNCUnMgLSB0cmFmZmljIG1heSBiZSBibGFja2hvbGVkIGV2ZW4gdGhvdWdoIHRoZXJlIGFyZSA4 IG90aGVyIEFTQlJzDQo+IGF2YWlsYWJsZS4gVGhlIGRyYWZ0IGNsZWFybHkgbWVudGlvbnMgdGhh dCBlYWNoIFJSIGNhbiBiZSBhbGxvdHRlZCBhbg0KPiBSUiBzcGVjaWZpYyBSVC4gU28gbGV0cyBz YXkgUlIxIGhhcyBhbiBSVCBvZiBYIGFuZCBSUjIgaGFzIFkuIFRoZSBQRTENCj4gY2FuIGFubm91 bmNlIGludGVyZXN0IGluIFJUICJYIiBhbmQgUlQgIlkiIGluIGFkZGl0aW9uIHRvICJBIiBhbmQN Cj4gIkIiLiBUaGlzIGlzIGEgY29tbW9uIGRlcGxveW1lbnQgd2hlcmUsIFJSMSBhbmQgUlIyIHdp bGwgYm90aA0KPiBhbm5vdW5jZSBwcmVmaXhlcyB0aGF0IG1hdGNoICJBIiBhbmQgIkIiIHBsdXMg dGhlIGJlc3QgcGF0aCBmb3IgYWxsDQo+IHByZWZpeGVzIHRoYXQgaXQgaXMgYXdhcmUgb2YgKFBy ZWZpeGVzIHdpdGggUlQgZXh0ZW5kZWQgY29tbXVuaXRpZXMNCj4gYW5kIHByZWZpeGVzIHRoYXQg bWF5IGJlIGFubm91bmNlZCB3aXRob3V0IFJUIGV4dGVuZGVkIGNvbW11bml0eSkuDQo+IFRoaXMg d2lsbCBlbnN1cmUgdGhhdCBQRTEgcmVjZWl2ZXMgMiBhZGRpdGlvbmFsIHBhdGhzIGZyb20gUlIx IGFuZA0KPiBSUjIgd2hpY2ggY2FuIGJlIHVzZWQgYXMgYmFja3VwIGluIHRoZSBldmVudCBvZiBw cmVmaXhlcyBub3QgYmVpbmcNCj4gYXZhaWxhYmxlIGZyb20gUlQgIkEiIGFuZCAiQiIuIFRoaXMg d2lsbCBlbnN1cmUgdGhhdCB0cmFmZmljIHdpbGwNCj4gbmV2ZXIgYmUgYmxhY2staG9sZWQgYXQg YWxsICh1bnRpbCB2aWFibGUgcGF0aHMgZXhpc3QpLg0KPg0KPiAtPiAgV2hldGhlciBhIG5ldHdv cmsgZW50aXR5IG9yIGxvY2FsIGlzIGEgbWF0dGVyIG9mIGhvdyBtdWNoDQo+IGFkbWluaXN0cmF0 aXZlIG92ZXJoZWFkIHZzLiBmbGV4aWJpbGl0eSBjYW4gYmUgYWNoaWV2ZWQuIEluIHRoZSBjYXNl DQo+IG9mIHRoZSBOSCBkcmFmdCwgZWFjaCBQRSBuZWVkcyB0byBiZSBjb25maWd1cmVkIHdpdGgg YW4NCj4gYWRtaW5pc3RyYXRpdmUgZGlzdGFuY2UgdG8gZWFjaCBBU0JSIC0gaWYgd2UgbmVlZCB0 byBhY2hpZXZlDQo+IHNvbWV0aGluZyBzaW1pbGFyIHRvIHdoYXQgY2FuIGJlIGFjaGlldmVkIGJ5 IHVzaW5nIFJUcy4gVGhpcyBjYW4gYmUNCj4gY29tcGxleCwgc2luY2Ugd2Ugd291bGQgZW5kIHVw IGNhbGN1bGF0aW5nIGVhY2ggcGFpciAoUEUtQVNCUikgaW4NCj4gYWRkaXRpb24gdG8gdHJhZmZp YyBmbG93cyBuZWVkZWQgdG8gcHV0IGluIHZhbHVlcy4gT24gdGhlIGNvbnRyYXJ5DQo+IHVzZSBv ZiBSVHMgaXMgbm90aGluZyBuZXcgZm9yIG9wZXJhdG9ycy4gVXNpbmcgYXBwcm9wcmlhdGUgUlRz IHdvdWxkDQo+IGJlIHRoZSBvbmx5IHN0ZXAgaW52b2x2ZWQgaW4gcmVjZWl2aW5nIEFTQlIgcGF0 aHMuIEFkZGl0aW9uIG9mIG5ldw0KPiBwYXRocywgbWVhbnMgLSBqdXN0IGFkZGluZyBhbm90aGVy IFJUIGludGVyZXN0IG9yIHJlbW92aW5nIGl0IGV0YyBhbmQNCj4gZG9lcyBub3QgaW52b2x2ZSBy ZS1lbmdpbmVlcmluZyBtZXRyaWNzLg0KPg0KPiAtPiAgUlQgdXNlcyBleGlzdGluZyBCR1AgbWFj aGluZXJ5LCB0aGVyZWZvcmUgYW4gb3BlcmF0b3IgZG9lcyBub3QNCj4gbmVlZCB0byB3b3JyeSBh Ym91dCB0aGUgc3VwcG9ydCBvZiBhIG5ldyBjYXBhYmlsaXR5Lg0KPg0KPiAtPiAgVGhpcyBzb2x1 dGlvbiBwcm9wb3NlcyBhIHNjaGVtZSBvZiBhbm5vdW5jaW5nIGFmZmluaXRpZXMsIGV2ZW4gaW4N Cj4gdGhlIGNhc2Ugb2YgQURELVBBVEggbm90IGJlaW5nIHN1cHBvcnRlZCBvbiBQRXMgLSB3aGlj aCBpcyBhbg0KPiBhZHZhbnRhZ2UuIFNvIGEgUEUgY2FuIGp1c3QgaW5kaWNhdGUgYW4gUlQgdGhh dCBtYXRjaGVzIGFuIEFTQlIgdGhhdA0KPiBpcyBjbG9zZXN0IG9yIGFkbWluaXN0cmF0aXZlbHkg cHJlZmVycmVkIGFuZCBzdGlsbCBnZXQgdGhhdCBwYXRoDQo+IGFubm91bmNlZCBieSB0aGUgUlIu IEluIGFkZGl0aW9uIFJSIHNwZWNpZmljIFJUcyAoYXMgbWVudGlvbmVkIGFib3ZlKQ0KPiBjYW4g cHJvdmlkZSBiYWNrdXAgaW4gdGhlIGV2ZW50IG9mIHRoZSBwcmVmZXJyZWQgQVNCUiBsb3Npbmcg cHJlZml4ZXMNCj4gb3IgZ29pbmcgb2ZmbGluZS4NCj4NCj4gLT4gIERlLWNvdXBsaW5nIHRoZSBS UiBmcm9tIHBhdGggc2VsZWN0aW9uIHRocm91Z2ggaW50ZWxsaWdlbnQNCj4gcmVxdWVzdHMgdGhy b3VnaCBhZmZpbml0aWVzIGNhbiBjZXJ0YWlubHkgcmVkdWNlIHRoZSBvdmVyaGVhZCBvbiB0aGUN Cj4gUlIgKyB0aGUgY2h1cm4gY2F1c2VkIG9uIHRoZSBSUiBkdWUgdG8gU1BGIHJ1bnMuDQo+DQo+ IC0+ICBJdCBpcyB0aGUgZWFzZSBvZiBhZG9wdGlvbiAtIHNpbmNlIFJUIGhhcyBiZWVuIGRlcGxv eWVkIGZvciBhDQo+IHdoaWxlIG5vdyB3aGljaCBtYWtlcyBpdCBzaW1wbGVyLg0KPg0KPiBBIHVw ZGF0ZWQgdmVyc2lvbiAoMDEpIG9mIHRoZSBkcmFmdCBlbGFib3JhdGluZyBzb21lIG9mIHRoZXNl DQo+IHNjZW5hcmlvcyBpbiBsYXJnZSBkZXRhaWwgd2lsbCBiZSByZWxlYXNlZCBzaG9ydGx5Lg0K Pg0KPiBSZWdhcmRzDQo+DQo+IFZpbm9kIEpvc2VwaCBQcm9mZXNzaW9uYWwgU2VydmljZXMg4oCT IFNlcnZpY2UgUHJvdmlkZXIgRU1FQSBKdW5pcGVyDQo+IE5ldHdvcmtzDQo+ICBNOiArNDQgKDAp IDc1MDAgODM1IDg3NiBFOiB2am9zZXBoQGp1bmlwZXIubmV0DQo+DQo+DQo+DQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFJvYmVydCBSYXN6dWsNCj4gW21haWx0bzpyYXN6 dWtAY2lzY28uY29tXSBTZW50OiAwNyBKdW5lIDIwMTEgMTc6MjUgVG86IEFtaXQgS2hvcGthcg0K PiBDYzogaUx5YTsgVmlub2QgSm9zZXBoOyBpZHJAaWV0Zi5vcmc7IExhdXJlbnQgTGF2YWxsZWUg U3ViamVjdDogUmU6DQo+IFtJZHJdIG1vcmUgb24gZHJhZnQtdmlub2QtbGF2YWxsZWUtYmdwLW9w dGltYWwtcm91dGUtcmVmbGVjdGlvbg0KPg0KPiBIaSBBbWl0LA0KPg0KPj4gMy4gdGhlcmUgYXJl IHR3byBhcHByb2FjaGVzIHRvIHJlc29sdmUgdGhpcyBhLiBsZXQgdGhlIHJvdXRlDQo+PiByZWZs ZWN0b3IgbWFrZSBhIGRlY2lzaW9uIGZvciBldmVyeSBQRSBiYXNlZCBvbiBzb21lIGNyaXRlcmlh IChJR1ANCj4+IG1ldHJpYyBpbiB5b3VyIGRyYWZ0KSBiLiB0YWtlIHRoZSBSUiBvdXQgb2YgdGhl IHJvdXRlIHNlbGVjdGlvbg0KPj4gcHJvY2VzcyAob25lIG9mIHRoZSBtYWluIHJlYXNvbnMgZm9y IGV4aXN0ZW5jZSBvZiBBREQtUEFUSCkgYnV0IGluDQo+PiBhIHNjYWxhYmxlIG1hbm5lcg0KPg0K PiBTaW5jZSBDaGludGFuIGlzIGFsc28gYXBwYXJlbnRseSBpbiB0aGUgc2FtZSBhc3N1bXB0aW9u IGxldCBtZQ0KPiByZWl0ZXJhdGUgdGhhdCBiYXNlIE9SUiBJRFIgV0cgZHJhZnQgY2FuIHVzZSBJ R1AgbWV0cmljIG9yIGFuZ3VsYXINCj4gZGlzdGFuY2UgYXBwcm94aW1hdGlvbiB0ZWNobmlxdWVz IHRvIHNlbGVjdCBvcHRpbWFsIHBhdGhzLg0KPg0KPiBOb3cgaWYgb3B0aW1hbCBmb3IgYW4gb3Bl cmF0b3IgbWVhbnMgdG8gdXNlIGhpcyBvdGhlciBjcml0ZXJpYSB0aGUNCj4gTkgtU0FGSSBkcmFm dCBJbHlhIGFuZCBJIHdyb3RlIGNvbWVzIGhhbmR5IGFzICJtZXRyaWMiIHdoaWNoIFBFDQo+IHJl cGxpZXMgdG8gUlIgaXMganVzdCBhIG51bWJlci4gWWVzIGl0IGNvdWxkIGJlIHJlbGF0ZWQgdG8g SUdQIHZpZXcNCj4gb2YgUEUgdG8gc3VjaCBuZXh0IGhvcCwgYnV0IGVxdWFsbHkgd2VsbCBpdCBj YW4gYmUgcmVsYXRlZCB0bw0KPiBvcGVyYXRvcidzIGxvY2FsIHBvbGljeS4NCj4NCj4gU3VjaCBs b2NhbCBwb2xpY3kgbmVlZHMgdG8gYmUgY29uZmlndXJlZCBhbmQgZXhwcmVzc2VkIHNvbWVob3cu IFlvdXINCj4gZHJhZnQgcmVjb21tZW5kcyBjb25maWd1cmluZyBSVCB0byBtYXRjaCB3aGF0IHNh aWQgQVNCUnMgd291bGQgdXNlDQo+IGluIHJvdXRlIG1hcmtpbmcgd2hhdCBjbGVhcmx5IGlzIG1v cmUgY29tcGxleCB0aGVuIGFsbG9jYXRpbmcgbG9jYWwNCj4gdmFsdWUgYXMgbG9jYWwgdmFsdWUg ZG9lcyBub3QgcmVxdWlyZSBhIGNvcnJlbGF0aW9uIHdpdGggYW55IG90aGVyDQo+IG5ldHdvcmsg ZW50aXR5LiBUaGF0IHNlZW1zIHRvIGJlIGEgZGlmZmVyZW5jZSB5b3UgYXJlIG5vdCBzZWVpbmcu DQo+DQo+IFRoZSBib3R0b20gbGluZSBJRFIgV0cgZHJhZnQgKyBkcmFmdC12YXJsYXNoa2luLWJn cC1uaC1jb3N0IGFscmVhZHkNCj4gYWRkcmVzcyBhbGwgcG9zc2libGUgc2NlbmFyaW9zIHdoaWNo IHlvdSBtYXkgbmVlZCBieSB1c2luZyB5b3VyDQo+IGRyYWZ0Lg0KPg0KPiBJZiB0aGVyZSBpcyBz b21ldGhpbmcgaW4geW91ciBkcmFmdCB3aGljaCB0aGUgYWJvdmUgc2V0IGlzIG1pc3NpbmcNCj4g YW5kIHdoaWNoIGJ5IHVzaW5nIHRoZSBhYm92ZSB0d28gZHJhZnRzIGNvdWxkIG5vdCBiZSBhY2Nv bXBsaXNoZWQNCj4gcGxlYXNlIGNsZWFybHkgZXhwbGFpbi4NCj4NCj4gTWFueSB0aHgsIFIuDQoN Cg== From raszuk@cisco.com Wed Jun 8 06:29:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F5511E80BE for ; Wed, 8 Jun 2011 06:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.077 X-Spam-Level: X-Spam-Status: No, score=-10.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YNMCG6XUa6R for ; Wed, 8 Jun 2011 06:29:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7050011E80BB for ; Wed, 8 Jun 2011 06:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=9818; q=dns/txt; s=iport; t=1307539746; x=1308749346; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qpv0tyycd602J89WeTRQF9NCv68HUF2ZKhFEbRDr5eo=; b=HgpY0L9a6UVpdwJbV8akVZmsd5AzD+4uXHjYVB+kFo4plpi417q5wsSV 5bGerAxPJVKFlkh6EitY4MHmiQguctdGxKDrHc8bBeMpUNcea2bwpX/Ml tC59VglPYE+kViHXcmThNqwtU+nzZOaJ4foFy4dRcj9Lej0qKKQpeIpDB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMt3702rRDoG/2dsb2JhbABThEqhZ3eIcaEDgwAPAYoAkHCBK4NugQoEkRuETYsA X-IronPort-AV: E=Sophos;i="4.65,338,1304294400"; d="scan'208";a="710179794" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 08 Jun 2011 13:29:05 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p58DT2Dq017167; Wed, 8 Jun 2011 13:29:02 GMT Message-ID: <4DEF791B.6090500@cisco.com> Date: Wed, 08 Jun 2011 15:28:59 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:29:08 -0000 Vinod, In contrast using my proposal you do not to single touch any PE or any ASBR as what the default requirement for hot potato routing calls is the shortest IGP exit. And that is computed automatically without any RTs, any metrics or even without need for any BGP protocol extension. Only in the event of operator wishing to overwrite the IGP shortest exist choice he may on a case by case basis use a manual policy. In fact if you follow route server space (which can equally well be applicable to the current discussion) such policy preference of not sending some paths to some clients can be realized today already by dynamic community based instruction send from client to a route server in the shipping code. Completely no need to mess with any additional signaling is necessary. Especially if you are talking about 1-10 preference levels. In RS such solution must scale at min on 1-1000 range :). So to summarize I still see no practical case for your proposal to progress it any further. Cheers, R. > I would look at this way Robert. An operator may plan to allot a set > of RT values lets say (1-10) for a given POP/Region. The proposal > specifies the need for the implementation to support RT values as > ranges as well. So each PE in a region can just include a range of > RTs, and this may include all or near to complete RT values that may > be allotted in a POP. So when a new ASBR is added, all you need is > the ASBR to have the appropriate RT used. > > In contrast, you would need to re-engineer each PE to have a new > metric (administrative) towards the new ASBR. So in effect every PE > interested in that ASBR needs re-calculation (on what metric is to be > used and whether this ASBR is going to be the primary path or backup > and so on) and re-configuration. > > Regards > > Vinod Joseph Professional Services – Service Provider Europe Juniper > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net > > > > > -----Original Message----- From: Robert Raszuk > [mailto:raszuk@cisco.com] Sent: 08 June 2011 08:09 To: Vinod Joseph > Cc: Amit.Khopkar@sns.bskyb.com; ilya@nobulus.com; idr@ietf.org; > Laurent.Lavallee@sns.bskyb.com; Chintan.Shah@colt.net; > Gaurav.Thareja@colt.net Subject: Re: [Idr] more on > draft-vinod-lavallee-bgp-optimal-route-reflection > > Vinod, > >> PEs only signal interest via RT constrain and do not need to >> attach RTs to their local prefixes. > > If PEs are signaling their route preference interest via RT constrain > I would assume they would have to be configured with those RTs ahead > of time as well. > > If not how would the PE know what to signal in RT constrain towards > the RRs ? > > Thx, R. > > > >> Further elaborating on the amount of configurations required in >> this draft vs the other proposals. >> >> Only ASBRs need to be configured with Route targets when >> advertised to the RRs, and I am sure ASBRs are much fewer in number >> to PEs. The PEs only signal interest via RT constrain and do not >> need to attach RTs to their local prefixes. The reason: In most >> cases PE announced customer prefixes can be controlled using >> standard BGP methods, if these PE announced prefixes are not needed >> on an ASBR for some special reason. >> >> On the contrary, the other solution needs every PE to ASBR pair >> mapped with an administrative cost in cases where the IGP is not >> preferred for use. If you have situations where each PE or groups >> of PEs have diverse outbound traffic flow requirements, you would >> end up having to manually setup potentially huge number of PE+ASBR >> pairs. In the event of a new ASBR introduced in the network, all >> PEs that need to use this ASBR as a primary exit point will need >> reconfiguration. Using RT, only the ASBR will need to be configured >> to advertise its paths with an additional Route target that matches >> a given PEs preference - HENCE SINGLE TOUCH POINT! >> >> Regards >> >> Vinod Joseph Sent from my Blackberry Professional Services - >> Service Provider Europe, UK& Ireland Juniper Networks, Inc. +44 >> 7500 835 876 E: vjoseph@juniper.net >> >> >> >> >> ----- Original Message ----- From: Vinod Joseph To: >> raszuk@cisco.com; Amit >> Khopkar Cc: iLya; >> idr@ietf.org; Laurent >> Lavallee Sent: Tue Jun 07 >> 22:32:03 2011 Subject: RE: [Idr] more on >> draft-vinod-lavallee-bgp-optimal-route-reflection >> >> Robert, >> >> There has been some amount of confusion in regard to BGP speakers >> will handle traffic in the event of prefixes not being available >> on ASBRs that match the RT interest from a PEs perspective. Let me >> clarify this here: >> >> -> Let us assume that there are 10 ASBRs in a network with two >> RRs (RR1 and RR2) and each ASBR has an RT for its prefixes, and PE1 >> has expressed interest in two RTs - lets say "A" and "B"(two >> ASBRs). The RR would announce prefixes for these two ASBRs only to >> the PE, therefore in the event of prefixes not being available at >> these two ASBRs - traffic may be blackholed even though there are 8 >> other ASBRs available. The draft clearly mentions that each RR can >> be allotted an RR specific RT. So lets say RR1 has an RT of X and >> RR2 has Y. The PE1 can announce interest in RT "X" and RT "Y" in >> addition to "A" and "B". This is a common deployment where, RR1 and >> RR2 will both announce prefixes that match "A" and "B" plus the >> best path for all prefixes that it is aware of (Prefixes with RT >> extended communities and prefixes that may be announced without RT >> extended community). This will ensure that PE1 receives 2 >> additional paths from RR1 and RR2 which can be used as backup in >> the event of prefixes not being available from RT "A" and "B". This >> will ensure that traffic will never be black-holed at all (until >> viable paths exist). >> >> -> Whether a network entity or local is a matter of how much >> administrative overhead vs. flexibility can be achieved. In the >> case of the NH draft, each PE needs to be configured with an >> administrative distance to each ASBR - if we need to achieve >> something similar to what can be achieved by using RTs. This can >> be complex, since we would end up calculating each pair (PE-ASBR) >> in addition to traffic flows needed to put in values. On the >> contrary use of RTs is nothing new for operators. Using appropriate >> RTs would be the only step involved in receiving ASBR paths. >> Addition of new paths, means - just adding another RT interest or >> removing it etc and does not involve re-engineering metrics. >> >> -> RT uses existing BGP machinery, therefore an operator does >> not need to worry about the support of a new capability. >> >> -> This solution proposes a scheme of announcing affinities, even >> in the case of ADD-PATH not being supported on PEs - which is an >> advantage. So a PE can just indicate an RT that matches an ASBR >> that is closest or administratively preferred and still get that >> path announced by the RR. In addition RR specific RTs (as mentioned >> above) can provide backup in the event of the preferred ASBR losing >> prefixes or going offline. >> >> -> De-coupling the RR from path selection through intelligent >> requests through affinities can certainly reduce the overhead on >> the RR + the churn caused on the RR due to SPF runs. >> >> -> It is the ease of adoption - since RT has been deployed for a >> while now which makes it simpler. >> >> A updated version (01) of the draft elaborating some of these >> scenarios in large detail will be released shortly. >> >> Regards >> >> Vinod Joseph Professional Services – Service Provider EMEA Juniper >> Networks M: +44 (0) 7500 835 876 E: vjoseph@juniper.net >> >> >> >> >> -----Original Message----- From: Robert Raszuk >> [mailto:raszuk@cisco.com] Sent: 07 June 2011 17:25 To: Amit >> Khopkar Cc: iLya; Vinod Joseph; idr@ietf.org; Laurent Lavallee >> Subject: Re: [Idr] more on >> draft-vinod-lavallee-bgp-optimal-route-reflection >> >> Hi Amit, >> >>> 3. there are two approaches to resolve this a. let the route >>> reflector make a decision for every PE based on some criteria >>> (IGP metric in your draft) b. take the RR out of the route >>> selection process (one of the main reasons for existence of >>> ADD-PATH) but in a scalable manner >> >> Since Chintan is also apparently in the same assumption let me >> reiterate that base ORR IDR WG draft can use IGP metric or angular >> distance approximation techniques to select optimal paths. >> >> Now if optimal for an operator means to use his other criteria the >> NH-SAFI draft Ilya and I wrote comes handy as "metric" which PE >> replies to RR is just a number. Yes it could be related to IGP >> view of PE to such next hop, but equally well it can be related to >> operator's local policy. >> >> Such local policy needs to be configured and expressed somehow. >> Your draft recommends configuring RT to match what said ASBRs would >> use in route marking what clearly is more complex then allocating >> local value as local value does not require a correlation with any >> other network entity. That seems to be a difference you are not >> seeing. >> >> The bottom line IDR WG draft + draft-varlashkin-bgp-nh-cost >> already address all possible scenarios which you may need by using >> your draft. >> >> If there is something in your draft which the above set is missing >> and which by using the above two drafts could not be accomplished >> please clearly explain. >> >> Many thx, R. > From stephane.litkowski@orange-ftgroup.com Wed Jun 8 06:33:06 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B30B11E80E4 for ; Wed, 8 Jun 2011 06:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.531 X-Spam-Level: ** X-Spam-Status: No, score=2.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, J_CHICKENPOX_25=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXfqWu6-8JUR for ; Wed, 8 Jun 2011 06:33:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 02D8711E80E3 for ; Wed, 8 Jun 2011 06:33:03 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id E54843743DE; Wed, 8 Jun 2011 15:33:02 +0200 (CEST) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id BD409158060; Wed, 8 Jun 2011 15:33:02 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jun 2011 15:33:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 15:33:00 +0200 Message-ID: <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36EE3646A09DAA60429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95AAB7/C6AAAQPyYAABiCyQ References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1><4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> From: To: "Vinod Joseph" , X-OriginalArrivalTime: 08 Jun 2011 13:33:02.0838 (UTC) FILETIME=[974F9960:01CC25E0] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.8.130620 Cc: idr@ietf.org, "Thareja, Gaurav" , Amit Khopkar , Chintan.Shah@colt.net, laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:33:06 -0000 Thanks for the feedback. Regarding RTC behavior, I don't agree of your interpretation of the way it = works, you said : "There is no best path calculation when using RT constrai= n. The RR just picks the number of paths that match a given RT and advertis= e this to the PE." Maybe I'm wrong, but I hope Robert will correct us as he is one of people w= ho defined RTC :) For me, RTC doesn't change anything to the way BGP is globally working. RTC= was designed to work for VPNs (first IPv4 but now it can be used for all V= PN types). RTC is just a way to signal an interrest for a BGP speaker for a= specific set of VPN prefixes matching some RTs (with end to end possibilit= y to propagate it). This signalling will lead for the peer who received the= RT NLRI to install a per peer ORF. And imo that's all. So if you take this case (VPN) : PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT2 RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 =09=09 RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT1 RR1 still compute best path per VPN prefix (in your case it will be IPv4 bu= t it doesn't really matter). RD1:X/Y label z -> Path2 is best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 will advertise these best path to the peers, especially PE1, but i= t has an ORF for PE1 which match only RT1, so only RD2:A/B and RD3:A/B will= be sent, RD1:X/Y will not because it doesn't have the community. What I mean by this, is that if you consider your case (IPv4), you will hav= e this : PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked with RT1 = and ASBR2 marked with RT2. PE1 will signal his interrested for RT1 and RT2. RR1 owns all IPv4 path from ASBRs, if we consider only one prefix X/Y recei= ved from all the ASBRs, we have this : X/Y Path 1 -> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=3DASBR2 (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=3DASBR3 (IGP cost c), LP 100, ASPATH c, RT3 ... Path x -> NH=3DASBRx (IGP cost x), LP 100, ASPATH x, RTx RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 peer. RR1 selects best path for all prefixes, and so for X/Y, it will choose one = path, the best for him, based on his own criteria. So if it selects for exa= mple Path3 as best, no path will be exported to PE1 :( All, pls correct me if I'm wrong. Thanks, =09 -----Message d'origine----- De : Vinod Joseph [mailto:vjoseph@juniper.net]=20 Envoy=E9 : mercredi 8 juin 2011 15:01 =C0 : LITKOWSKI Stephane DTF/DERX Cc : idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; Chintan.Sh= ah@colt.net; Thareja, Gaurav Objet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Hi Stephane, Comments inline as Vinod# Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com [mailto:stephane.litkowski@oran= ge-ftgroup.com] Sent: 08 June 2011 13:25 To: Vinod Joseph Cc: idr@ietf.org Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Hi Vinod, Some comments your the draft, I followed quickly all the discussions on the= subject on this mailing list but I have some questions more oriented on ho= w your system is explained in your document. I understand globally your idea, and I agree with Robert on the fact that y= our draft is not proposing an optimal route-reflection but more an "ingress= preference-based" route-reflection. I understand your explanation about wh= at is behind the word "optimal" but generally optimal is always shortest IG= P :) otherwise this is more preference based routing. Vinod# I am open to suggestions as you mentioned to changed the word "optim= al" to something else - if that helps. Carriers do define optimal as being = the closest IGP next-hop and this scheme does permit that to be achieved us= ing preferences indicated via RT Constrain. As you mention, it moves one st= ep further in permitting preference based routing (if you like). Do keep in= mind that this proposal does use the IGP metric as the tie breaker in any = case. For instance if a BGP speaker indicates a preference for RT:X, and if= RT:X has 4 paths, which get advertised by the RR to the PE - Then the PE u= nder normal conditions will choose the NH with the closest IGP metric anywa= ys.=20 To go more deeper in your text, in the =A75.2, you are talking about "The o= bjective here is to ensure that the "best path" based on the shortest IGP m= etric from each PE to an ASBR is announced by the RR.". I don't really agre= e on that, because your ingress router is able to choose the paths that wil= l be given to him by the RR using the RT mechanism. So it could , or could= not be the shortest IGP metric path (the operator is choosing by himself).= So If my understanding of your system is good, imo a rephrasing could be n= ecessary to explain the exact goal/possibilities of your system. I agree th= at you can achieve hot potatoe routing with your system, but it is just a s= ubcase of a more global approach. Vinod# Yes. But Like I mentioned the tie breaker when multiple paths are an= nounced to a PE is the shortest IGP metric. Therefore if the operator decid= es that he only wants a set of ASBRs chosen for traffic exit - the choice w= ithin those set of paths will always be the closest ASBR. Then you propose to use RT Constraint for IPv4 AFI/SAFI, as mentionned by R= obert, today RTC is not done per AFI/SAFI, so you will have to deal with th= is and not interfer with current VPNs deployed (especially if you are mixin= g IPv4/VPNv4 on RRs), it's not blocking but operator must be aware of this = when deploying your solution. Moreover you are not using basic RTC like we do for VPNv4, because you need= to modify the RR behavior to be able to compute "best path" per peer or pe= r peer-group : this is not done today with current RTC. RTC in VPNv4 is wor= king fine because of unicity of prefixes ensured by RD, but this is not the= case for IPv4. You need to modify the way best path is computed. RTC, it's= just putting an ORF ;) but without modifying best path computation, we are= just filtering the RIB-OUT. We can guess this in your document, but imho t= his is not clearly explained. So what is your approach here : - 1) using ADD-PATH "export all" in addition to RTC, so all routes are put= ted in RIB-OUT then filtered towards PE by the RR based on the RT-ORF ? - 2) modify the best path mechanism, create a per peer/peer-group path eli= gible group (based on RTC infos), then do ADDPATH to export all paths or so= me paths inside this group ? - 3) Something else ? Vinod# There is another version of the draft clearly mentioning these scena= rios in detail and I did mention this in email to Robert yesterday. There i= s no best path calculation when using RT constrain. The RR just picks the n= umber of paths that match a given RT and advertise this to the PE. So there= would be no advantage in exporting all paths to the RIB-OUT and then filte= ring prefixes/paths based on RT-ORF. The ideal approach would instead be to= create a per peer-group based model where appropriate RT paths are only an= nounced. The best path calculation is only performed when an RR specific RT= is announced. I had emailed this yesterday, wherein a PE can signal an RT = that is allocated to a given set of RR(s), and the RR(s) just announce the = best path for all prefixes ir-respective of whether an RT is attached or no= t.=20 Another point, RTC is a complex BGP machinery, new AFI/SAFI, new way to pro= pagate this AFI/SAFI ... But here in fact you just need a point to point me= chanism, why not using RT based ORF, or simply a BGP standard community bas= ed ORF ? If your ASBRs are marking routes using a special CT (normal 32bits= community), PE can choose this ASBR by just signalling a CT based ORF to t= he RR (in combination with ADD-PATH) ?. So there is nothing new to implemen= t (except CT based ORF, but ORF idea is globally already existing). Then you have to take into account that your ingress router need to receive= routes other than ASBR routes, so your mechanism must not prevent that. If= you are using RTC, you will receive only routes matching your RT, potentia= lly "internal" routes will not be received anymore if you don't marked them= with an RT imported by all your routers. Vinod# Standard communities are already used for various purposes such as f= iltering which customer routes get installed where and so on.... and we did= not want to dilute this by using standard communities for another whole ne= w purpose. The intent of this proposal is to leverage existing machinery - = RT and RT constrain exists in all code and deployments. We ensure that the = PE router will receive all routes other than routes matching the RT, and th= is is done by allotting an RT per RR as I mentioned in my previous emails. = Each PE just needs to signal these RR specific RTs or an RR specific RT to = get the best path for all other prefixes other than the interested RT alone= . Therefore there never be a situation where a PE will be starved of routin= g information if ASBRs that match the RTs signalled via RTC lose visibility= to any prefixes. Keep in mind that this proposal can work with existing machinery as well i.= e. if ADD-PATH is yet to be supported on PEs. In the event of PEs not suppo= rting ADD-PATH, the RR would only send a single path per RT that gets signa= lled.=20 Let me know your thought, Best Regards, Stephane =20 ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre pro= tegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message et t= ous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named r= ecipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From vjoseph@juniper.net Wed Jun 8 06:35:56 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D4911E80C5 for ; Wed, 8 Jun 2011 06:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.941 X-Spam-Level: X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0FRkvKYkfEY for ; Wed, 8 Jun 2011 06:35:55 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3F86411E80BB for ; Wed, 8 Jun 2011 06:35:52 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTe96spM9JWEeoVYb2PhBNyhcP++WCFSV@postini.com; Wed, 08 Jun 2011 06:35:55 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 06:33:38 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 14:33:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 8 Jun 2011 14:33:35 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: Acwl4AzwFR4HJ9umSl6zY3BzrkhaPQAACuEA References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> From: Vinod Joseph To: X-OriginalArrivalTime: 08 Jun 2011 13:33:36.0813 (UTC) FILETIME=[AB8FC5D0:01CC25E0] Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:35:56 -0000 Um9iZXJ0LA0KDQpCdXQgdGhlIGZhY3Qgb2YgcnVubmluZyBTUEYgb24gYmVoYWxmIG9mIGEgUEUg ZG9lcyBub3Qgc2NhbGUgaW4gYSBsYXJnZSBjYXJyaWVyIGVudmlyb25tZW50LCBpdCB0cmFuc2xh dGVzIHRvICdidXJuaW5nIiB0aGUgUlIgdG8ga2VlcCB1cCB0byBldmVyeSBzaW5nbGUgY2hhbmdl IGluIHRoZSBuZXR3b3JrIGFuZCB0byBjYWxjdWxhdGUgYmVzdCBwYXRoIHRvIEFTQlJzIDotKQ0K UmVnYXJkcw0KDQpWaW5vZCBKb3NlcGgNClByb2Zlc3Npb25hbCBTZXJ2aWNlcyDigJMgU2Vydmlj ZSBQcm92aWRlciBFdXJvcGUNCkp1bmlwZXIgTmV0d29ya3PCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoA0K TTogKzQ0ICgwKSA3NTAwIDgzNSA4NzYNCkU6wqB2am9zZXBoQGp1bmlwZXIubmV0DQrCoA0KDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvYmVydCBSYXN6dWsgW21haWx0 bzpyYXN6dWtAY2lzY28uY29tXSANClNlbnQ6IDA4IEp1bmUgMjAxMSAxNDoyOQ0KVG86IFZpbm9k IEpvc2VwaA0KQ2M6IEFtaXQuS2hvcGthckBzbnMuYnNreWIuY29tOyBpbHlhQG5vYnVsdXMuY29t OyBpZHJAaWV0Zi5vcmc7IExhdXJlbnQuTGF2YWxsZWVAc25zLmJza3liLmNvbTsgQ2hpbnRhbi5T aGFoQGNvbHQubmV0OyBHYXVyYXYuVGhhcmVqYUBjb2x0Lm5ldA0KU3ViamVjdDogUmU6IFtJZHJd IG1vcmUgb24gZHJhZnQtdmlub2QtbGF2YWxsZWUtYmdwLW9wdGltYWwtcm91dGUtcmVmbGVjdGlv bg0KDQpWaW5vZCwNCg0KSW4gY29udHJhc3QgdXNpbmcgbXkgcHJvcG9zYWwgeW91IGRvIG5vdCB0 byBzaW5nbGUgdG91Y2ggYW55IFBFIG9yIGFueSANCkFTQlIgYXMgd2hhdCB0aGUgZGVmYXVsdCBy ZXF1aXJlbWVudCBmb3IgaG90IHBvdGF0byByb3V0aW5nIGNhbGxzIGlzIHRoZSANCnNob3J0ZXN0 IElHUCBleGl0LiBBbmQgdGhhdCBpcyBjb21wdXRlZCBhdXRvbWF0aWNhbGx5IHdpdGhvdXQgYW55 IFJUcywgDQphbnkgbWV0cmljcyBvciBldmVuIHdpdGhvdXQgbmVlZCBmb3IgYW55IEJHUCBwcm90 b2NvbCBleHRlbnNpb24uDQoNCk9ubHkgaW4gdGhlIGV2ZW50IG9mIG9wZXJhdG9yIHdpc2hpbmcg dG8gb3ZlcndyaXRlIHRoZSBJR1Agc2hvcnRlc3QgDQpleGlzdCBjaG9pY2UgaGUgbWF5IG9uIGEg Y2FzZSBieSBjYXNlIGJhc2lzIHVzZSBhIG1hbnVhbCBwb2xpY3kuDQoNCkluIGZhY3QgaWYgeW91 IGZvbGxvdyByb3V0ZSBzZXJ2ZXIgc3BhY2UgKHdoaWNoIGNhbiBlcXVhbGx5IHdlbGwgYmUgDQph cHBsaWNhYmxlIHRvIHRoZSBjdXJyZW50IGRpc2N1c3Npb24pIHN1Y2ggcG9saWN5IHByZWZlcmVu Y2Ugb2Ygbm90IA0Kc2VuZGluZyBzb21lIHBhdGhzIHRvIHNvbWUgY2xpZW50cyBjYW4gYmUgcmVh bGl6ZWQgdG9kYXkgYWxyZWFkeSBieSANCmR5bmFtaWMgY29tbXVuaXR5IGJhc2VkIGluc3RydWN0 aW9uIHNlbmQgZnJvbSBjbGllbnQgdG8gYSByb3V0ZSBzZXJ2ZXIgDQppbiB0aGUgc2hpcHBpbmcg Y29kZS4gQ29tcGxldGVseSBubyBuZWVkIHRvIG1lc3Mgd2l0aCBhbnkgYWRkaXRpb25hbCANCnNp Z25hbGluZyBpcyBuZWNlc3NhcnkuIEVzcGVjaWFsbHkgaWYgeW91IGFyZSB0YWxraW5nIGFib3V0 IDEtMTAgDQpwcmVmZXJlbmNlIGxldmVscy4gSW4gUlMgc3VjaCBzb2x1dGlvbiBtdXN0IHNjYWxl IGF0IG1pbiBvbiAxLTEwMDAgcmFuZ2UgDQo6KS4NCg0KU28gdG8gc3VtbWFyaXplIEkgc3RpbGwg c2VlIG5vIHByYWN0aWNhbCBjYXNlIGZvciB5b3VyIHByb3Bvc2FsIHRvIA0KcHJvZ3Jlc3MgaXQg YW55IGZ1cnRoZXIuDQoNCkNoZWVycywNClIuDQoNCg0KPiBJIHdvdWxkIGxvb2sgYXQgdGhpcyB3 YXkgUm9iZXJ0LiBBbiBvcGVyYXRvciBtYXkgcGxhbiB0byBhbGxvdCBhIHNldA0KPiBvZiBSVCB2 YWx1ZXMgbGV0cyBzYXkgKDEtMTApIGZvciBhIGdpdmVuIFBPUC9SZWdpb24uIFRoZSBwcm9wb3Nh bA0KPiBzcGVjaWZpZXMgdGhlIG5lZWQgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbiB0byBzdXBwb3J0 IFJUIHZhbHVlcyBhcw0KPiByYW5nZXMgYXMgd2VsbC4gU28gZWFjaCBQRSBpbiBhIHJlZ2lvbiBj YW4ganVzdCBpbmNsdWRlIGEgcmFuZ2Ugb2YNCj4gUlRzLCBhbmQgdGhpcyBtYXkgaW5jbHVkZSBh bGwgb3IgbmVhciB0byBjb21wbGV0ZSBSVCB2YWx1ZXMgdGhhdCBtYXkNCj4gYmUgYWxsb3R0ZWQg aW4gYSBQT1AuIFNvIHdoZW4gYSBuZXcgQVNCUiBpcyBhZGRlZCwgYWxsIHlvdSBuZWVkIGlzDQo+ IHRoZSBBU0JSIHRvIGhhdmUgdGhlIGFwcHJvcHJpYXRlIFJUIHVzZWQuDQo+DQo+IEluIGNvbnRy YXN0LCB5b3Ugd291bGQgbmVlZCB0byByZS1lbmdpbmVlciBlYWNoIFBFIHRvIGhhdmUgYSBuZXcN Cj4gbWV0cmljIChhZG1pbmlzdHJhdGl2ZSkgdG93YXJkcyB0aGUgbmV3IEFTQlIuIFNvIGluIGVm ZmVjdCBldmVyeSBQRQ0KPiBpbnRlcmVzdGVkIGluIHRoYXQgQVNCUiBuZWVkcyByZS1jYWxjdWxh dGlvbiAob24gd2hhdCBtZXRyaWMgaXMgdG8gYmUNCj4gdXNlZCBhbmQgd2hldGhlciB0aGlzIEFT QlIgaXMgZ29pbmcgdG8gYmUgdGhlIHByaW1hcnkgcGF0aCBvciBiYWNrdXANCj4gYW5kIHNvIG9u KSBhbmQgcmUtY29uZmlndXJhdGlvbi4NCj4NCj4gUmVnYXJkcw0KPg0KPiBWaW5vZCBKb3NlcGgg UHJvZmVzc2lvbmFsIFNlcnZpY2VzIOKAkyBTZXJ2aWNlIFByb3ZpZGVyIEV1cm9wZSBKdW5pcGVy DQo+IE5ldHdvcmtzDQo+ICBNOiArNDQgKDApIDc1MDAgODM1IDg3NiBFOiB2am9zZXBoQGp1bmlw ZXIubmV0DQo+DQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFJv YmVydCBSYXN6dWsNCj4gW21haWx0bzpyYXN6dWtAY2lzY28uY29tXSBTZW50OiAwOCBKdW5lIDIw MTEgMDg6MDkgVG86IFZpbm9kIEpvc2VwaA0KPiBDYzogQW1pdC5LaG9wa2FyQHNucy5ic2t5Yi5j b207IGlseWFAbm9idWx1cy5jb207IGlkckBpZXRmLm9yZzsNCj4gTGF1cmVudC5MYXZhbGxlZUBz bnMuYnNreWIuY29tOyBDaGludGFuLlNoYWhAY29sdC5uZXQ7DQo+IEdhdXJhdi5UaGFyZWphQGNv bHQubmV0IFN1YmplY3Q6IFJlOiBbSWRyXSBtb3JlIG9uDQo+IGRyYWZ0LXZpbm9kLWxhdmFsbGVl LWJncC1vcHRpbWFsLXJvdXRlLXJlZmxlY3Rpb24NCj4NCj4gVmlub2QsDQo+DQo+PiBQRXMgb25s eSBzaWduYWwgaW50ZXJlc3QgdmlhIFJUIGNvbnN0cmFpbiBhbmQgZG8gbm90IG5lZWQgdG8NCj4+ IGF0dGFjaCBSVHMgdG8gdGhlaXIgbG9jYWwgcHJlZml4ZXMuDQo+DQo+IElmIFBFcyBhcmUgc2ln bmFsaW5nIHRoZWlyIHJvdXRlIHByZWZlcmVuY2UgaW50ZXJlc3QgdmlhIFJUIGNvbnN0cmFpbg0K PiBJIHdvdWxkIGFzc3VtZSB0aGV5IHdvdWxkIGhhdmUgdG8gYmUgY29uZmlndXJlZCB3aXRoIHRo b3NlIFJUcyBhaGVhZA0KPiBvZiB0aW1lIGFzIHdlbGwuDQo+DQo+IElmIG5vdCBob3cgd291bGQg dGhlIFBFIGtub3cgd2hhdCB0byBzaWduYWwgaW4gUlQgY29uc3RyYWluIHRvd2FyZHMNCj4gdGhl IFJScyA/DQo+DQo+IFRoeCwgUi4NCj4NCj4NCj4NCj4+IEZ1cnRoZXIgZWxhYm9yYXRpbmcgb24g dGhlIGFtb3VudCBvZiBjb25maWd1cmF0aW9ucyByZXF1aXJlZCBpbg0KPj4gdGhpcyBkcmFmdCB2 cyB0aGUgb3RoZXIgcHJvcG9zYWxzLg0KPj4NCj4+IE9ubHkgQVNCUnMgbmVlZCB0byBiZSBjb25m aWd1cmVkIHdpdGggUm91dGUgdGFyZ2V0cyB3aGVuDQo+PiBhZHZlcnRpc2VkIHRvIHRoZSBSUnMs IGFuZCBJIGFtIHN1cmUgQVNCUnMgYXJlIG11Y2ggZmV3ZXIgaW4gbnVtYmVyDQo+PiB0byBQRXMu IFRoZSBQRXMgb25seSBzaWduYWwgaW50ZXJlc3QgdmlhIFJUIGNvbnN0cmFpbiBhbmQgZG8gbm90 DQo+PiBuZWVkIHRvIGF0dGFjaCBSVHMgdG8gdGhlaXIgbG9jYWwgcHJlZml4ZXMuIFRoZSByZWFz b246IEluIG1vc3QNCj4+IGNhc2VzIFBFIGFubm91bmNlZCBjdXN0b21lciBwcmVmaXhlcyBjYW4g YmUgY29udHJvbGxlZCB1c2luZw0KPj4gc3RhbmRhcmQgQkdQIG1ldGhvZHMsIGlmIHRoZXNlIFBF IGFubm91bmNlZCBwcmVmaXhlcyBhcmUgbm90IG5lZWRlZA0KPj4gb24gYW4gQVNCUiBmb3Igc29t ZSBzcGVjaWFsIHJlYXNvbi4NCj4+DQo+PiBPbiB0aGUgY29udHJhcnksIHRoZSBvdGhlciBzb2x1 dGlvbiBuZWVkcyBldmVyeSBQRSB0byBBU0JSIHBhaXINCj4+IG1hcHBlZCB3aXRoIGFuIGFkbWlu aXN0cmF0aXZlIGNvc3QgaW4gY2FzZXMgd2hlcmUgdGhlIElHUCBpcyBub3QNCj4+IHByZWZlcnJl ZCBmb3IgdXNlLiBJZiB5b3UgaGF2ZSBzaXR1YXRpb25zIHdoZXJlIGVhY2ggUEUgb3IgZ3JvdXBz DQo+PiBvZiBQRXMgaGF2ZSBkaXZlcnNlIG91dGJvdW5kIHRyYWZmaWMgZmxvdyByZXF1aXJlbWVu dHMsIHlvdSB3b3VsZA0KPj4gZW5kIHVwIGhhdmluZyB0byBtYW51YWxseSBzZXR1cCBwb3RlbnRp YWxseSBodWdlIG51bWJlciBvZiBQRStBU0JSDQo+PiBwYWlycy4gSW4gdGhlIGV2ZW50IG9mIGEg bmV3IEFTQlIgaW50cm9kdWNlZCBpbiB0aGUgbmV0d29yaywgYWxsDQo+PiBQRXMgdGhhdCBuZWVk IHRvIHVzZSB0aGlzIEFTQlIgYXMgYSBwcmltYXJ5IGV4aXQgcG9pbnQgd2lsbCBuZWVkDQo+PiBy ZWNvbmZpZ3VyYXRpb24uIFVzaW5nIFJULCBvbmx5IHRoZSBBU0JSIHdpbGwgbmVlZCB0byBiZSBj b25maWd1cmVkDQo+PiB0byBhZHZlcnRpc2UgaXRzIHBhdGhzIHdpdGggYW4gYWRkaXRpb25hbCBS b3V0ZSB0YXJnZXQgdGhhdCBtYXRjaGVzDQo+PiBhIGdpdmVuIFBFcyBwcmVmZXJlbmNlIC0gSEVO Q0UgU0lOR0xFIFRPVUNIIFBPSU5UIQ0KPj4NCj4+IFJlZ2FyZHMNCj4+DQo+PiBWaW5vZCBKb3Nl cGggU2VudCBmcm9tIG15IEJsYWNrYmVycnkgUHJvZmVzc2lvbmFsIFNlcnZpY2VzIC0NCj4+IFNl cnZpY2UgUHJvdmlkZXIgRXVyb3BlLCBVSyYgICBJcmVsYW5kIEp1bmlwZXIgTmV0d29ya3MsIElu Yy4gKzQ0DQo+PiA3NTAwIDgzNSA4NzYgRTogdmpvc2VwaEBqdW5pcGVyLm5ldA0KPj4NCj4+DQo+ Pg0KPj4NCj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gRnJvbTogVmlub2QgSm9zZXBo IFRvOg0KPj4gcmFzenVrQGNpc2NvLmNvbTxyYXN6dWtAY2lzY28uY29tPjsgQW1pdA0KPj4gS2hv cGthcjxBbWl0Lktob3BrYXJAc25zLmJza3liLmNvbT4gIENjOiBpTHlhPGlseWFAbm9idWx1cy5j b20+Ow0KPj4gaWRyQGlldGYub3JnPGlkckBpZXRmLm9yZz47IExhdXJlbnQNCj4+IExhdmFsbGVl PExhdXJlbnQuTGF2YWxsZWVAc25zLmJza3liLmNvbT4gIFNlbnQ6IFR1ZSBKdW4gMDcNCj4+IDIy OjMyOjAzIDIwMTEgU3ViamVjdDogUkU6IFtJZHJdIG1vcmUgb24NCj4+IGRyYWZ0LXZpbm9kLWxh dmFsbGVlLWJncC1vcHRpbWFsLXJvdXRlLXJlZmxlY3Rpb24NCj4+DQo+PiBSb2JlcnQsDQo+Pg0K Pj4gVGhlcmUgaGFzIGJlZW4gc29tZSBhbW91bnQgb2YgY29uZnVzaW9uIGluIHJlZ2FyZCB0byBC R1Agc3BlYWtlcnMNCj4+IHdpbGwgaGFuZGxlIHRyYWZmaWMgaW4gdGhlIGV2ZW50IG9mIHByZWZp eGVzIG5vdCBiZWluZyBhdmFpbGFibGUNCj4+IG9uIEFTQlJzIHRoYXQgbWF0Y2ggdGhlIFJUIGlu dGVyZXN0IGZyb20gYSBQRXMgcGVyc3BlY3RpdmUuIExldCBtZQ0KPj4gY2xhcmlmeSB0aGlzIGhl cmU6DQo+Pg0KPj4gLT4gICBMZXQgdXMgYXNzdW1lIHRoYXQgdGhlcmUgYXJlIDEwIEFTQlJzIGlu IGEgbmV0d29yayB3aXRoIHR3bw0KPj4gUlJzIChSUjEgYW5kIFJSMikgYW5kIGVhY2ggQVNCUiBo YXMgYW4gUlQgZm9yIGl0cyBwcmVmaXhlcywgYW5kIFBFMQ0KPj4gaGFzIGV4cHJlc3NlZCBpbnRl cmVzdCBpbiB0d28gUlRzIC0gbGV0cyBzYXkgIkEiIGFuZCAiQiIodHdvDQo+PiBBU0JScykuIFRo ZSBSUiB3b3VsZCBhbm5vdW5jZSBwcmVmaXhlcyBmb3IgdGhlc2UgdHdvIEFTQlJzIG9ubHkgdG8N Cj4+IHRoZSBQRSwgdGhlcmVmb3JlIGluIHRoZSBldmVudCBvZiBwcmVmaXhlcyBub3QgYmVpbmcg YXZhaWxhYmxlIGF0DQo+PiB0aGVzZSB0d28gQVNCUnMgLSB0cmFmZmljIG1heSBiZSBibGFja2hv bGVkIGV2ZW4gdGhvdWdoIHRoZXJlIGFyZSA4DQo+PiBvdGhlciBBU0JScyBhdmFpbGFibGUuIFRo ZSBkcmFmdCBjbGVhcmx5IG1lbnRpb25zIHRoYXQgZWFjaCBSUiBjYW4NCj4+IGJlIGFsbG90dGVk IGFuIFJSIHNwZWNpZmljIFJULiBTbyBsZXRzIHNheSBSUjEgaGFzIGFuIFJUIG9mIFggYW5kDQo+ PiBSUjIgaGFzIFkuIFRoZSBQRTEgY2FuIGFubm91bmNlIGludGVyZXN0IGluIFJUICJYIiBhbmQg UlQgIlkiIGluDQo+PiBhZGRpdGlvbiB0byAiQSIgYW5kICJCIi4gVGhpcyBpcyBhIGNvbW1vbiBk ZXBsb3ltZW50IHdoZXJlLCBSUjEgYW5kDQo+PiBSUjIgd2lsbCBib3RoIGFubm91bmNlIHByZWZp eGVzIHRoYXQgbWF0Y2ggIkEiIGFuZCAiQiIgcGx1cyB0aGUNCj4+IGJlc3QgcGF0aCBmb3IgYWxs IHByZWZpeGVzIHRoYXQgaXQgaXMgYXdhcmUgb2YgKFByZWZpeGVzIHdpdGggUlQNCj4+IGV4dGVu ZGVkIGNvbW11bml0aWVzIGFuZCBwcmVmaXhlcyB0aGF0IG1heSBiZSBhbm5vdW5jZWQgd2l0aG91 dCBSVA0KPj4gZXh0ZW5kZWQgY29tbXVuaXR5KS4gVGhpcyB3aWxsIGVuc3VyZSB0aGF0IFBFMSBy ZWNlaXZlcyAyDQo+PiBhZGRpdGlvbmFsIHBhdGhzIGZyb20gUlIxIGFuZCBSUjIgd2hpY2ggY2Fu IGJlIHVzZWQgYXMgYmFja3VwIGluDQo+PiB0aGUgZXZlbnQgb2YgcHJlZml4ZXMgbm90IGJlaW5n IGF2YWlsYWJsZSBmcm9tIFJUICJBIiBhbmQgIkIiLiBUaGlzDQo+PiB3aWxsIGVuc3VyZSB0aGF0 IHRyYWZmaWMgd2lsbCBuZXZlciBiZSBibGFjay1ob2xlZCBhdCBhbGwgKHVudGlsDQo+PiB2aWFi bGUgcGF0aHMgZXhpc3QpLg0KPj4NCj4+IC0+ICAgV2hldGhlciBhIG5ldHdvcmsgZW50aXR5IG9y IGxvY2FsIGlzIGEgbWF0dGVyIG9mIGhvdyBtdWNoDQo+PiBhZG1pbmlzdHJhdGl2ZSBvdmVyaGVh ZCB2cy4gZmxleGliaWxpdHkgY2FuIGJlIGFjaGlldmVkLiBJbiB0aGUNCj4+IGNhc2Ugb2YgdGhl IE5IIGRyYWZ0LCBlYWNoIFBFIG5lZWRzIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCBhbg0KPj4gYWRt aW5pc3RyYXRpdmUgZGlzdGFuY2UgdG8gZWFjaCBBU0JSIC0gaWYgd2UgbmVlZCB0byBhY2hpZXZl DQo+PiBzb21ldGhpbmcgc2ltaWxhciB0byB3aGF0IGNhbiBiZSBhY2hpZXZlZCBieSB1c2luZyBS VHMuIFRoaXMgY2FuDQo+PiBiZSBjb21wbGV4LCBzaW5jZSB3ZSB3b3VsZCBlbmQgdXAgY2FsY3Vs YXRpbmcgZWFjaCBwYWlyIChQRS1BU0JSKQ0KPj4gaW4gYWRkaXRpb24gdG8gdHJhZmZpYyBmbG93 cyBuZWVkZWQgdG8gcHV0IGluIHZhbHVlcy4gT24gdGhlDQo+PiBjb250cmFyeSB1c2Ugb2YgUlRz IGlzIG5vdGhpbmcgbmV3IGZvciBvcGVyYXRvcnMuIFVzaW5nIGFwcHJvcHJpYXRlDQo+PiBSVHMg d291bGQgYmUgdGhlIG9ubHkgc3RlcCBpbnZvbHZlZCBpbiByZWNlaXZpbmcgQVNCUiBwYXRocy4N Cj4+IEFkZGl0aW9uIG9mIG5ldyBwYXRocywgbWVhbnMgLSBqdXN0IGFkZGluZyBhbm90aGVyIFJU IGludGVyZXN0IG9yDQo+PiByZW1vdmluZyBpdCBldGMgYW5kIGRvZXMgbm90IGludm9sdmUgcmUt ZW5naW5lZXJpbmcgbWV0cmljcy4NCj4+DQo+PiAtPiAgIFJUIHVzZXMgZXhpc3RpbmcgQkdQIG1h Y2hpbmVyeSwgdGhlcmVmb3JlIGFuIG9wZXJhdG9yIGRvZXMNCj4+IG5vdCBuZWVkIHRvIHdvcnJ5 IGFib3V0IHRoZSBzdXBwb3J0IG9mIGEgbmV3IGNhcGFiaWxpdHkuDQo+Pg0KPj4gLT4gICBUaGlz IHNvbHV0aW9uIHByb3Bvc2VzIGEgc2NoZW1lIG9mIGFubm91bmNpbmcgYWZmaW5pdGllcywgZXZl bg0KPj4gaW4gdGhlIGNhc2Ugb2YgQURELVBBVEggbm90IGJlaW5nIHN1cHBvcnRlZCBvbiBQRXMg LSB3aGljaCBpcyBhbg0KPj4gYWR2YW50YWdlLiBTbyBhIFBFIGNhbiBqdXN0IGluZGljYXRlIGFu IFJUIHRoYXQgbWF0Y2hlcyBhbiBBU0JSDQo+PiB0aGF0IGlzIGNsb3Nlc3Qgb3IgYWRtaW5pc3Ry YXRpdmVseSBwcmVmZXJyZWQgYW5kIHN0aWxsIGdldCB0aGF0DQo+PiBwYXRoIGFubm91bmNlZCBi eSB0aGUgUlIuIEluIGFkZGl0aW9uIFJSIHNwZWNpZmljIFJUcyAoYXMgbWVudGlvbmVkDQo+PiBh Ym92ZSkgY2FuIHByb3ZpZGUgYmFja3VwIGluIHRoZSBldmVudCBvZiB0aGUgcHJlZmVycmVkIEFT QlIgbG9zaW5nDQo+PiBwcmVmaXhlcyBvciBnb2luZyBvZmZsaW5lLg0KPj4NCj4+IC0+ICAgRGUt Y291cGxpbmcgdGhlIFJSIGZyb20gcGF0aCBzZWxlY3Rpb24gdGhyb3VnaCBpbnRlbGxpZ2VudA0K Pj4gcmVxdWVzdHMgdGhyb3VnaCBhZmZpbml0aWVzIGNhbiBjZXJ0YWlubHkgcmVkdWNlIHRoZSBv dmVyaGVhZCBvbg0KPj4gdGhlIFJSICsgdGhlIGNodXJuIGNhdXNlZCBvbiB0aGUgUlIgZHVlIHRv IFNQRiBydW5zLg0KPj4NCj4+IC0+ICAgSXQgaXMgdGhlIGVhc2Ugb2YgYWRvcHRpb24gLSBzaW5j ZSBSVCBoYXMgYmVlbiBkZXBsb3llZCBmb3IgYQ0KPj4gd2hpbGUgbm93IHdoaWNoIG1ha2VzIGl0 IHNpbXBsZXIuDQo+Pg0KPj4gQSB1cGRhdGVkIHZlcnNpb24gKDAxKSBvZiB0aGUgZHJhZnQgZWxh Ym9yYXRpbmcgc29tZSBvZiB0aGVzZQ0KPj4gc2NlbmFyaW9zIGluIGxhcmdlIGRldGFpbCB3aWxs IGJlIHJlbGVhc2VkIHNob3J0bHkuDQo+Pg0KPj4gUmVnYXJkcw0KPj4NCj4+IFZpbm9kIEpvc2Vw aCBQcm9mZXNzaW9uYWwgU2VydmljZXMg4oCTIFNlcnZpY2UgUHJvdmlkZXIgRU1FQSBKdW5pcGVy DQo+PiBOZXR3b3JrcyBNOiArNDQgKDApIDc1MDAgODM1IDg3NiBFOiB2am9zZXBoQGp1bmlwZXIu bmV0DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTog Um9iZXJ0IFJhc3p1aw0KPj4gW21haWx0bzpyYXN6dWtAY2lzY28uY29tXSBTZW50OiAwNyBKdW5l IDIwMTEgMTc6MjUgVG86IEFtaXQNCj4+IEtob3BrYXIgQ2M6IGlMeWE7IFZpbm9kIEpvc2VwaDsg aWRyQGlldGYub3JnOyBMYXVyZW50IExhdmFsbGVlDQo+PiBTdWJqZWN0OiBSZTogW0lkcl0gbW9y ZSBvbg0KPj4gZHJhZnQtdmlub2QtbGF2YWxsZWUtYmdwLW9wdGltYWwtcm91dGUtcmVmbGVjdGlv bg0KPj4NCj4+IEhpIEFtaXQsDQo+Pg0KPj4+IDMuIHRoZXJlIGFyZSB0d28gYXBwcm9hY2hlcyB0 byByZXNvbHZlIHRoaXMgYS4gbGV0IHRoZSByb3V0ZQ0KPj4+IHJlZmxlY3RvciBtYWtlIGEgZGVj aXNpb24gZm9yIGV2ZXJ5IFBFIGJhc2VkIG9uIHNvbWUgY3JpdGVyaWENCj4+PiAoSUdQIG1ldHJp YyBpbiB5b3VyIGRyYWZ0KSBiLiB0YWtlIHRoZSBSUiBvdXQgb2YgdGhlIHJvdXRlDQo+Pj4gc2Vs ZWN0aW9uIHByb2Nlc3MgKG9uZSBvZiB0aGUgbWFpbiByZWFzb25zIGZvciBleGlzdGVuY2Ugb2YN Cj4+PiBBREQtUEFUSCkgYnV0IGluIGEgc2NhbGFibGUgbWFubmVyDQo+Pg0KPj4gU2luY2UgQ2hp bnRhbiBpcyBhbHNvIGFwcGFyZW50bHkgaW4gdGhlIHNhbWUgYXNzdW1wdGlvbiBsZXQgbWUNCj4+ IHJlaXRlcmF0ZSB0aGF0IGJhc2UgT1JSIElEUiBXRyBkcmFmdCBjYW4gdXNlIElHUCBtZXRyaWMg b3IgYW5ndWxhcg0KPj4gZGlzdGFuY2UgYXBwcm94aW1hdGlvbiB0ZWNobmlxdWVzIHRvIHNlbGVj dCBvcHRpbWFsIHBhdGhzLg0KPj4NCj4+IE5vdyBpZiBvcHRpbWFsIGZvciBhbiBvcGVyYXRvciBt ZWFucyB0byB1c2UgaGlzIG90aGVyIGNyaXRlcmlhIHRoZQ0KPj4gTkgtU0FGSSBkcmFmdCBJbHlh IGFuZCBJIHdyb3RlIGNvbWVzIGhhbmR5IGFzICJtZXRyaWMiIHdoaWNoIFBFDQo+PiByZXBsaWVz IHRvIFJSIGlzIGp1c3QgYSBudW1iZXIuIFllcyBpdCBjb3VsZCBiZSByZWxhdGVkIHRvIElHUA0K Pj4gdmlldyBvZiBQRSB0byBzdWNoIG5leHQgaG9wLCBidXQgZXF1YWxseSB3ZWxsIGl0IGNhbiBi ZSByZWxhdGVkIHRvDQo+PiBvcGVyYXRvcidzIGxvY2FsIHBvbGljeS4NCj4+DQo+PiBTdWNoIGxv Y2FsIHBvbGljeSBuZWVkcyB0byBiZSBjb25maWd1cmVkIGFuZCBleHByZXNzZWQgc29tZWhvdy4N Cj4+IFlvdXIgZHJhZnQgcmVjb21tZW5kcyBjb25maWd1cmluZyBSVCB0byBtYXRjaCB3aGF0IHNh aWQgQVNCUnMgd291bGQNCj4+IHVzZSBpbiByb3V0ZSBtYXJraW5nIHdoYXQgY2xlYXJseSBpcyBt b3JlIGNvbXBsZXggdGhlbiBhbGxvY2F0aW5nDQo+PiBsb2NhbCB2YWx1ZSBhcyBsb2NhbCB2YWx1 ZSBkb2VzIG5vdCByZXF1aXJlIGEgY29ycmVsYXRpb24gd2l0aCBhbnkNCj4+IG90aGVyIG5ldHdv cmsgZW50aXR5LiBUaGF0IHNlZW1zIHRvIGJlIGEgZGlmZmVyZW5jZSB5b3UgYXJlIG5vdA0KPj4g c2VlaW5nLg0KPj4NCj4+IFRoZSBib3R0b20gbGluZSBJRFIgV0cgZHJhZnQgKyBkcmFmdC12YXJs YXNoa2luLWJncC1uaC1jb3N0DQo+PiBhbHJlYWR5IGFkZHJlc3MgYWxsIHBvc3NpYmxlIHNjZW5h cmlvcyB3aGljaCB5b3UgbWF5IG5lZWQgYnkgdXNpbmcNCj4+IHlvdXIgZHJhZnQuDQo+Pg0KPj4g SWYgdGhlcmUgaXMgc29tZXRoaW5nIGluIHlvdXIgZHJhZnQgd2hpY2ggdGhlIGFib3ZlIHNldCBp cyBtaXNzaW5nDQo+PiBhbmQgd2hpY2ggYnkgdXNpbmcgdGhlIGFib3ZlIHR3byBkcmFmdHMgY291 bGQgbm90IGJlIGFjY29tcGxpc2hlZA0KPj4gcGxlYXNlIGNsZWFybHkgZXhwbGFpbi4NCj4+DQo+ PiBNYW55IHRoeCwgUi4NCj4NCg0K From vjoseph@juniper.net Wed Jun 8 06:40:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA4A11E812A for ; Wed, 8 Jun 2011 06:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.855 X-Spam-Level: X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=-2.035, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_21=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAqDB1k1fZi9 for ; Wed, 8 Jun 2011 06:40:54 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 84A3411E8104 for ; Wed, 8 Jun 2011 06:40:47 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTe973rYe1Yb+oY4r5Hi3FSv7rQB5Tf+x@postini.com; Wed, 08 Jun 2011 06:40:54 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 06:37:46 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 14:37:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 14:37:35 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C069970E2@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95AAB7/C6AAAQPyYAABiCyQAAC9IDA= References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1><4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC35 56A36EE3 646A09DAA60429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> From: Vinod Joseph To: , X-OriginalArrivalTime: 08 Jun 2011 13:37:36.0344 (UTC) FILETIME=[3A554D80:01CC25E1] Cc: idr@ietf.org, "Thareja, Gaurav" , Amit Khopkar , Chintan.Shah@colt.net, laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:40:55 -0000 Inline -=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com]=20 Sent: 08 June 2011 14:33 To: Vinod Joseph; raszuk@cisco.com Cc: idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Subject: RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Thanks for the feedback. Regarding RTC behavior, I don't agree of your interpretation of the way = it works, you said : "There is no best path calculation when using RT = constrain. The RR just picks the number of paths that match a given RT = and advertise this to the PE." Maybe I'm wrong, but I hope Robert will correct us as he is one of = people who defined RTC :) For me, RTC doesn't change anything to the way BGP is globally working. = RTC was designed to work for VPNs (first IPv4 but now it can be used for = all VPN types). RTC is just a way to signal an interrest for a BGP = speaker for a specific set of VPN prefixes matching some RTs (with end = to end possibility to propagate it). This signalling will lead for the = peer who received the RT NLRI to install a per peer ORF. And imo that's = all. So if you take this case (VPN) : PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT2 RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 =09 RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT1 RR1 still compute best path per VPN prefix (in your case it will be IPv4 = but it doesn't really matter). RD1:X/Y label z -> Path2 is best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 will advertise these best path to the peers, especially PE1, = but it has an ORF for PE1 which match only RT1, so only RD2:A/B and = RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the = community. What I mean by this, is that if you consider your case (IPv4), you will = have this : PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked with = RT1 and ASBR2 marked with RT2. PE1 will signal his interrested for RT1 and RT2. RR1 owns all IPv4 path from ASBRs, if we consider only one prefix X/Y = received from all the ASBRs, we have this : X/Y Path 1 -> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=3DASBR2 (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=3DASBR3 (IGP cost c), LP 100, ASPATH c, RT3 ... Path x -> NH=3DASBRx (IGP cost x), LP 100, ASPATH x, RTx RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 peer. RR1 selects best path for all prefixes, and so for X/Y, it will choose = one path, the best for him, based on his own criteria. So if it selects = for example Path3 as best, no path will be exported to PE1 :( Vinod# So what are proposing is: Use ADD-PATH for announcing not just = the best path but all paths that match a given RT. So in your example, = RR1 will not do a best path calc, and instead advertise Path1 and Path2 = which match RT1 and RT2. Otherwise we are not adding any value here :-) All, pls correct me if I'm wrong. Thanks, =09 -----Message d'origine----- De : Vinod Joseph [mailto:vjoseph@juniper.net]=20 Envoy=E9 : mercredi 8 juin 2011 15:01 =C0 : LITKOWSKI Stephane DTF/DERX Cc : idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Objet : RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Hi Stephane, Comments inline as Vinod# Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com] Sent: 08 June 2011 13:25 To: Vinod Joseph Cc: idr@ietf.org Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Hi Vinod, Some comments your the draft, I followed quickly all the discussions on = the subject on this mailing list but I have some questions more oriented = on how your system is explained in your document. I understand globally your idea, and I agree with Robert on the fact = that your draft is not proposing an optimal route-reflection but more an = "ingress preference-based" route-reflection. I understand your = explanation about what is behind the word "optimal" but generally = optimal is always shortest IGP :) otherwise this is more preference = based routing. Vinod# I am open to suggestions as you mentioned to changed the word = "optimal" to something else - if that helps. Carriers do define optimal = as being the closest IGP next-hop and this scheme does permit that to be = achieved using preferences indicated via RT Constrain. As you mention, = it moves one step further in permitting preference based routing (if you = like). Do keep in mind that this proposal does use the IGP metric as the = tie breaker in any case. For instance if a BGP speaker indicates a = preference for RT:X, and if RT:X has 4 paths, which get advertised by = the RR to the PE - Then the PE under normal conditions will choose the = NH with the closest IGP metric anyways.=20 To go more deeper in your text, in the =A75.2, you are talking about = "The objective here is to ensure that the "best path" based on the = shortest IGP metric from each PE to an ASBR is announced by the RR.". I = don't really agree on that, because your ingress router is able to = choose the paths that will be given to him by the RR using the RT = mechanism. So it could , or could not be the shortest IGP metric path = (the operator is choosing by himself). So If my understanding of your = system is good, imo a rephrasing could be necessary to explain the exact = goal/possibilities of your system. I agree that you can achieve hot = potatoe routing with your system, but it is just a subcase of a more = global approach. Vinod# Yes. But Like I mentioned the tie breaker when multiple paths are = announced to a PE is the shortest IGP metric. Therefore if the operator = decides that he only wants a set of ASBRs chosen for traffic exit - the = choice within those set of paths will always be the closest ASBR. Then you propose to use RT Constraint for IPv4 AFI/SAFI, as mentionned = by Robert, today RTC is not done per AFI/SAFI, so you will have to deal = with this and not interfer with current VPNs deployed (especially if you = are mixing IPv4/VPNv4 on RRs), it's not blocking but operator must be = aware of this when deploying your solution. Moreover you are not using basic RTC like we do for VPNv4, because you = need to modify the RR behavior to be able to compute "best path" per = peer or per peer-group : this is not done today with current RTC. RTC in = VPNv4 is working fine because of unicity of prefixes ensured by RD, but = this is not the case for IPv4. You need to modify the way best path is = computed. RTC, it's just putting an ORF ;) but without modifying best = path computation, we are just filtering the RIB-OUT. We can guess this = in your document, but imho this is not clearly explained. So what is = your approach here : - 1) using ADD-PATH "export all" in addition to RTC, so all routes are = putted in RIB-OUT then filtered towards PE by the RR based on the RT-ORF = ? - 2) modify the best path mechanism, create a per peer/peer-group path = eligible group (based on RTC infos), then do ADDPATH to export all paths = or some paths inside this group ? - 3) Something else ? Vinod# There is another version of the draft clearly mentioning these = scenarios in detail and I did mention this in email to Robert yesterday. = There is no best path calculation when using RT constrain. The RR just = picks the number of paths that match a given RT and advertise this to = the PE. So there would be no advantage in exporting all paths to the = RIB-OUT and then filtering prefixes/paths based on RT-ORF. The ideal = approach would instead be to create a per peer-group based model where = appropriate RT paths are only announced. The best path calculation is = only performed when an RR specific RT is announced. I had emailed this = yesterday, wherein a PE can signal an RT that is allocated to a given = set of RR(s), and the RR(s) just announce the best path for all prefixes = ir-respective of whether an RT is attached or not.=20 Another point, RTC is a complex BGP machinery, new AFI/SAFI, new way to = propagate this AFI/SAFI ... But here in fact you just need a point to = point mechanism, why not using RT based ORF, or simply a BGP standard = community based ORF ? If your ASBRs are marking routes using a special = CT (normal 32bits community), PE can choose this ASBR by just signalling = a CT based ORF to the RR (in combination with ADD-PATH) ?. So there is = nothing new to implement (except CT based ORF, but ORF idea is globally = already existing). Then you have to take into account that your ingress router need to = receive routes other than ASBR routes, so your mechanism must not = prevent that. If you are using RTC, you will receive only routes = matching your RT, potentially "internal" routes will not be received = anymore if you don't marked them with an RT imported by all your = routers. Vinod# Standard communities are already used for various purposes such = as filtering which customer routes get installed where and so on.... and = we did not want to dilute this by using standard communities for another = whole new purpose. The intent of this proposal is to leverage existing = machinery - RT and RT constrain exists in all code and deployments. We = ensure that the PE router will receive all routes other than routes = matching the RT, and this is done by allotting an RT per RR as I = mentioned in my previous emails. Each PE just needs to signal these RR = specific RTs or an RR specific RT to get the best path for all other = prefixes other than the interested RT alone. Therefore there never be a = situation where a PE will be starved of routing information if ASBRs = that match the RTs signalled via RTC lose visibility to any prefixes. Keep in mind that this proposal can work with existing machinery as well = i.e. if ADD-PATH is yet to be supported on PEs. In the event of PEs not = supporting ADD-PATH, the RR would only send a single path per RT that = gets signalled.=20 Let me know your thought, Best Regards, Stephane =20 *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et = peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only = for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* From stephane.litkowski@orange-ftgroup.com Wed Jun 8 07:05:28 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E8D21F849D for ; Wed, 8 Jun 2011 07:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=-2.389, BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdzzV0WfjKVL for ; Wed, 8 Jun 2011 07:05:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 20D5D21F851A for ; Wed, 8 Jun 2011 07:05:22 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id AA0A118C4D2; Wed, 8 Jun 2011 16:05:21 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8A37535C05B; Wed, 8 Jun 2011 16:05:21 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jun 2011 16:05:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 16:05:21 +0200 Message-ID: <15908_1307541921_4DEF81A1_15908_25798_1_4FC3556A36EE3646A09DAA60429F5335067BBAF6@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <5DD781A4BE13384A900438DF0608972C069970E2@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95AAB7/C6AAAQPyYAABiCyQAAC9IDAAAKjLQA== References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1><4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC35 56A36EE 3646A09DAA60 429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970E2@emailemea4.jnpr.net> From: To: "Vinod Joseph" , X-OriginalArrivalTime: 08 Jun 2011 14:05:21.0622 (UTC) FILETIME=[1AEA8F60:01CC25E5] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.8.130620 Cc: idr@ietf.org, "Thareja, Gaurav" , Amit Khopkar , Chintan.Shah@colt.net, laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:05:28 -0000 Yes for me you have to use ADD path in addition to RTC to make it working o= r change the BGP best path computation. But you are mentionning : "use ADD-PATH for announcing not just the best pa= th but all paths that match a given RT" It is imo possible to do it, ADD PATH is just a transport mechanism but doe= sn't presume on how path are selected. But today, the way you need is not described in draft-uttaro-idr-add-paths-= guidelines (export n paths matching some attributes), so an update might be= needed ... Best Regards, Stephane -----Message d'origine----- De : Vinod Joseph [mailto:vjoseph@juniper.net]=20 Envoy=E9 : mercredi 8 juin 2011 15:38 =C0 : LITKOWSKI Stephane DTF/DERX; raszuk@cisco.com Cc : idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; Chintan.Sh= ah@colt.net; Thareja, Gaurav Objet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Inline -=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com [mailto:stephane.litkowski@oran= ge-ftgroup.com] Sent: 08 June 2011 14:33 To: Vinod Joseph; raszuk@cisco.com Cc: idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; Chintan.Sha= h@colt.net; Thareja, Gaurav Subject: RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thanks for the feedback. Regarding RTC behavior, I don't agree of your interpretation of the way it = works, you said : "There is no best path calculation when using RT constrai= n. The RR just picks the number of paths that match a given RT and advertis= e this to the PE." Maybe I'm wrong, but I hope Robert will correct us as he is one of people w= ho defined RTC :) For me, RTC doesn't change anything to the way BGP is glo= bally working. RTC was designed to work for VPNs (first IPv4 but now it can= be used for all VPN types). RTC is just a way to signal an interrest for a= BGP speaker for a specific set of VPN prefixes matching some RTs (with end= to end possibility to propagate it). This signalling will lead for the pee= r who received the RT NLRI to install a per peer ORF. And imo that's all. So if you take this case (VPN) : PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT2 RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 =09=09 RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT1 RR1 still compute best path per VPN prefix (in your case it will be IPv4 bu= t it doesn't really matter). RD1:X/Y label z -> Path2 is best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 will advertise these best path to the peers, especially PE1, but i= t has an ORF for PE1 which match only RT1, so only RD2:A/B and RD3:A/B will= be sent, RD1:X/Y will not because it doesn't have the community. What I mean by this, is that if you consider your case (IPv4), you will hav= e this : PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked with RT1 = and ASBR2 marked with RT2. PE1 will signal his interrested for RT1 and RT2. RR1 owns all IPv4 path from ASBRs, if we consider only one prefix X/Y recei= ved from all the ASBRs, we have this : X/Y Path 1 -> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=3DASBR2 (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=3DASBR3 (IGP cost c), LP 100, ASPATH c, RT3 ... Path x -> NH=3DASBRx (IGP cost x), LP 100, ASPATH x, RTx RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 peer. RR1 selects best path for all prefixes, and so for X/Y, it will choose one = path, the best for him, based on his own criteria. So if it selects for exa= mple Path3 as best, no path will be exported to PE1 :( Vinod# So what are proposing is: Use ADD-PATH for announcing not just the b= est path but all paths that match a given RT. So in your example, RR1 will = not do a best path calc, and instead advertise Path1 and Path2 which match = RT1 and RT2. Otherwise we are not adding any value here :-) All, pls correct me if I'm wrong. Thanks, =09 -----Message d'origine----- De : Vinod Joseph [mailto:vjoseph@juniper.net] Envoy=E9 : mercredi 8 juin 2= 011 15:01 =C0 : LITKOWSKI Stephane DTF/DERX Cc : idr@ietf.org; laurent.lava= llee@sns.bskyb.com; Amit Khopkar; Chintan.Shah@colt.net; Thareja, Gaurav Ob= jet : RE: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Hi Stephane, Comments inline as Vinod# Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com [mailto:stephane.litkowski@oran= ge-ftgroup.com] Sent: 08 June 2011 13:25 To: Vinod Joseph Cc: idr@ietf.org Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Hi Vinod, Some comments your the draft, I followed quickly all the discussions on the= subject on this mailing list but I have some questions more oriented on ho= w your system is explained in your document. I understand globally your idea, and I agree with Robert on the fact that y= our draft is not proposing an optimal route-reflection but more an "ingress= preference-based" route-reflection. I understand your explanation about wh= at is behind the word "optimal" but generally optimal is always shortest IG= P :) otherwise this is more preference based routing. Vinod# I am open to suggestions as you mentioned to changed the word "optim= al" to something else - if that helps. Carriers do define optimal as being = the closest IGP next-hop and this scheme does permit that to be achieved us= ing preferences indicated via RT Constrain. As you mention, it moves one st= ep further in permitting preference based routing (if you like). Do keep in= mind that this proposal does use the IGP metric as the tie breaker in any = case. For instance if a BGP speaker indicates a preference for RT:X, and if= RT:X has 4 paths, which get advertised by the RR to the PE - Then the PE u= nder normal conditions will choose the NH with the closest IGP metric anywa= ys.=20 To go more deeper in your text, in the =A75.2, you are talking about "The o= bjective here is to ensure that the "best path" based on the shortest IGP m= etric from each PE to an ASBR is announced by the RR.". I don't really agre= e on that, because your ingress router is able to choose the paths that wil= l be given to him by the RR using the RT mechanism. So it could , or could= not be the shortest IGP metric path (the operator is choosing by himself).= So If my understanding of your system is good, imo a rephrasing could be n= ecessary to explain the exact goal/possibilities of your system. I agree th= at you can achieve hot potatoe routing with your system, but it is just a s= ubcase of a more global approach. Vinod# Yes. But Like I mentioned the tie breaker when multiple paths are an= nounced to a PE is the shortest IGP metric. Therefore if the operator decid= es that he only wants a set of ASBRs chosen for traffic exit - the choice w= ithin those set of paths will always be the closest ASBR. Then you propose to use RT Constraint for IPv4 AFI/SAFI, as mentionned by R= obert, today RTC is not done per AFI/SAFI, so you will have to deal with th= is and not interfer with current VPNs deployed (especially if you are mixin= g IPv4/VPNv4 on RRs), it's not blocking but operator must be aware of this = when deploying your solution. Moreover you are not using basic RTC like we do for VPNv4, because you need= to modify the RR behavior to be able to compute "best path" per peer or pe= r peer-group : this is not done today with current RTC. RTC in VPNv4 is wor= king fine because of unicity of prefixes ensured by RD, but this is not the= case for IPv4. You need to modify the way best path is computed. RTC, it's= just putting an ORF ;) but without modifying best path computation, we are= just filtering the RIB-OUT. We can guess this in your document, but imho t= his is not clearly explained. So what is your approach here : - 1) using ADD-PATH "export all" in addition to RTC, so all routes are put= ted in RIB-OUT then filtered towards PE by the RR based on the RT-ORF ? - 2) modify the best path mechanism, create a per peer/peer-group path eli= gible group (based on RTC infos), then do ADDPATH to export all paths or so= me paths inside this group ? - 3) Something else ? Vinod# There is another version of the draft clearly mentioning these scena= rios in detail and I did mention this in email to Robert yesterday. There i= s no best path calculation when using RT constrain. The RR just picks the n= umber of paths that match a given RT and advertise this to the PE. So there= would be no advantage in exporting all paths to the RIB-OUT and then filte= ring prefixes/paths based on RT-ORF. The ideal approach would instead be to= create a per peer-group based model where appropriate RT paths are only an= nounced. The best path calculation is only performed when an RR specific RT= is announced. I had emailed this yesterday, wherein a PE can signal an RT = that is allocated to a given set of RR(s), and the RR(s) just announce the = best path for all prefixes ir-respective of whether an RT is attached or no= t.=20 Another point, RTC is a complex BGP machinery, new AFI/SAFI, new way to pro= pagate this AFI/SAFI ... But here in fact you just need a point to point me= chanism, why not using RT based ORF, or simply a BGP standard community bas= ed ORF ? If your ASBRs are marking routes using a special CT (normal 32bits= community), PE can choose this ASBR by just signalling a CT based ORF to t= he RR (in combination with ADD-PATH) ?. So there is nothing new to implemen= t (except CT based ORF, but ORF idea is globally already existing). Then you have to take into account that your ingress router need to receive= routes other than ASBR routes, so your mechanism must not prevent that. If= you are using RTC, you will receive only routes matching your RT, potentia= lly "internal" routes will not be received anymore if you don't marked them= with an RT imported by all your routers. Vinod# Standard communities are already used for various purposes such as f= iltering which customer routes get installed where and so on.... and we did= not want to dilute this by using standard communities for another whole ne= w purpose. The intent of this proposal is to leverage existing machinery - = RT and RT constrain exists in all code and deployments. We ensure that the = PE router will receive all routes other than routes matching the RT, and th= is is done by allotting an RT per RR as I mentioned in my previous emails. = Each PE just needs to signal these RR specific RTs or an RR specific RT to = get the best path for all other prefixes other than the interested RT alone= . Therefore there never be a situation where a PE will be starved of routin= g information if ASBRs that match the RTs signalled via RTC lose visibility= to any prefixes. Keep in mind that this proposal can work with existing machinery as well i.= e. if ADD-PATH is yet to be supported on PEs. In the event of PEs not suppo= rting ADD-PATH, the RR would only send a single path per RT that gets signa= lled.=20 Let me know your thought, Best Regards, Stephane =20 ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre pro= tegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message et t= ous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named r= ecipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre pro= tegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message et t= ous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named r= ecipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From vjoseph@juniper.net Wed Jun 8 07:08:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329D521F8525 for ; Wed, 8 Jun 2011 07:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.728 X-Spam-Level: X-Spam-Status: No, score=-3.728 tagged_above=-999 required=5 tests=[AWL=-1.908, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_21=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+QB2lWGK4u9 for ; Wed, 8 Jun 2011 07:08:38 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 56F3721F8524 for ; Wed, 8 Jun 2011 07:08:31 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTe+CXjxdd5pxScdSX2uIXXRvWr2Znc8m@postini.com; Wed, 08 Jun 2011 07:08:37 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 07:07:00 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 15:06:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 15:06:58 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C069970F4@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95AAB7/C6AAAQPyYAABiCyQAAC9IDAAAKjLQAAAZ9mw References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1><4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC35 56A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970E2@emailemea4.jnpr.net> <15908_1307541921_4DEF81A1_15908_25798_1_4FC3556A36EE3646A09DAA60429F5335067BBAF6@PUEXCBL0.nanterre.francetelecom.fr> From: Vinod Joseph To: , X-OriginalArrivalTime: 08 Jun 2011 14:06:59.0532 (UTC) FILETIME=[554670C0:01CC25E5] Cc: idr@ietf.org, "Thareja, Gaurav" , Amit Khopkar , Chintan.Shah@colt.net, laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:08:39 -0000 Yes, version 0.1 of this draft will have more detail case studies taking = in the feedback that has been received from all on the list. Stay tuned for the next version shortly. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com]=20 Sent: 08 June 2011 15:05 To: Vinod Joseph; raszuk@cisco.com Cc: idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Subject: RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Yes for me you have to use ADD path in addition to RTC to make it = working or change the BGP best path computation. But you are mentionning : "use ADD-PATH for announcing not just the best = path but all paths that match a given RT" It is imo possible to do it, ADD PATH is just a transport mechanism but = doesn't presume on how path are selected. But today, the way you need is not described in = draft-uttaro-idr-add-paths-guidelines (export n paths matching some = attributes), so an update might be needed ... Best Regards, Stephane -----Message d'origine----- De : Vinod Joseph [mailto:vjoseph@juniper.net]=20 Envoy=E9 : mercredi 8 juin 2011 15:38 =C0 : LITKOWSKI Stephane DTF/DERX; raszuk@cisco.com Cc : idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Objet : RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Inline -=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com] Sent: 08 June 2011 14:33 To: Vinod Joseph; raszuk@cisco.com Cc: idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Subject: RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Thanks for the feedback. Regarding RTC behavior, I don't agree of your interpretation of the way = it works, you said : "There is no best path calculation when using RT = constrain. The RR just picks the number of paths that match a given RT = and advertise this to the PE." Maybe I'm wrong, but I hope Robert will correct us as he is one of = people who defined RTC :) For me, RTC doesn't change anything to the way = BGP is globally working. RTC was designed to work for VPNs (first IPv4 = but now it can be used for all VPN types). RTC is just a way to signal = an interrest for a BGP speaker for a specific set of VPN prefixes = matching some RTs (with end to end possibility to propagate it). This = signalling will lead for the peer who received the RT NLRI to install a = per peer ORF. And imo that's all. So if you take this case (VPN) : PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT2 RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 =09 RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT1 RR1 still compute best path per VPN prefix (in your case it will be IPv4 = but it doesn't really matter). RD1:X/Y label z -> Path2 is best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 will advertise these best path to the peers, especially PE1, = but it has an ORF for PE1 which match only RT1, so only RD2:A/B and = RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the = community. What I mean by this, is that if you consider your case (IPv4), you will = have this : PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked with = RT1 and ASBR2 marked with RT2. PE1 will signal his interrested for RT1 and RT2. RR1 owns all IPv4 path from ASBRs, if we consider only one prefix X/Y = received from all the ASBRs, we have this : X/Y Path 1 -> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=3DASBR2 (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=3DASBR3 (IGP cost c), LP 100, ASPATH c, RT3 ... Path x -> NH=3DASBRx (IGP cost x), LP 100, ASPATH x, RTx RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 peer. RR1 selects best path for all prefixes, and so for X/Y, it will choose = one path, the best for him, based on his own criteria. So if it selects = for example Path3 as best, no path will be exported to PE1 :( Vinod# So what are proposing is: Use ADD-PATH for announcing not just = the best path but all paths that match a given RT. So in your example, = RR1 will not do a best path calc, and instead advertise Path1 and Path2 = which match RT1 and RT2. Otherwise we are not adding any value here :-) All, pls correct me if I'm wrong. Thanks, =09 -----Message d'origine----- De : Vinod Joseph [mailto:vjoseph@juniper.net] Envoy=E9 : mercredi 8 = juin 2011 15:01 =C0 : LITKOWSKI Stephane DTF/DERX Cc : idr@ietf.org; = laurent.lavallee@sns.bskyb.com; Amit Khopkar; Chintan.Shah@colt.net; = Thareja, Gaurav Objet : RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Hi Stephane, Comments inline as Vinod# Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com] Sent: 08 June 2011 13:25 To: Vinod Joseph Cc: idr@ietf.org Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Hi Vinod, Some comments your the draft, I followed quickly all the discussions on = the subject on this mailing list but I have some questions more oriented = on how your system is explained in your document. I understand globally your idea, and I agree with Robert on the fact = that your draft is not proposing an optimal route-reflection but more an = "ingress preference-based" route-reflection. I understand your = explanation about what is behind the word "optimal" but generally = optimal is always shortest IGP :) otherwise this is more preference = based routing. Vinod# I am open to suggestions as you mentioned to changed the word = "optimal" to something else - if that helps. Carriers do define optimal = as being the closest IGP next-hop and this scheme does permit that to be = achieved using preferences indicated via RT Constrain. As you mention, = it moves one step further in permitting preference based routing (if you = like). Do keep in mind that this proposal does use the IGP metric as the = tie breaker in any case. For instance if a BGP speaker indicates a = preference for RT:X, and if RT:X has 4 paths, which get advertised by = the RR to the PE - Then the PE under normal conditions will choose the = NH with the closest IGP metric anyways.=20 To go more deeper in your text, in the =A75.2, you are talking about = "The objective here is to ensure that the "best path" based on the = shortest IGP metric from each PE to an ASBR is announced by the RR.". I = don't really agree on that, because your ingress router is able to = choose the paths that will be given to him by the RR using the RT = mechanism. So it could , or could not be the shortest IGP metric path = (the operator is choosing by himself). So If my understanding of your = system is good, imo a rephrasing could be necessary to explain the exact = goal/possibilities of your system. I agree that you can achieve hot = potatoe routing with your system, but it is just a subcase of a more = global approach. Vinod# Yes. But Like I mentioned the tie breaker when multiple paths are = announced to a PE is the shortest IGP metric. Therefore if the operator = decides that he only wants a set of ASBRs chosen for traffic exit - the = choice within those set of paths will always be the closest ASBR. Then you propose to use RT Constraint for IPv4 AFI/SAFI, as mentionned = by Robert, today RTC is not done per AFI/SAFI, so you will have to deal = with this and not interfer with current VPNs deployed (especially if you = are mixing IPv4/VPNv4 on RRs), it's not blocking but operator must be = aware of this when deploying your solution. Moreover you are not using basic RTC like we do for VPNv4, because you = need to modify the RR behavior to be able to compute "best path" per = peer or per peer-group : this is not done today with current RTC. RTC in = VPNv4 is working fine because of unicity of prefixes ensured by RD, but = this is not the case for IPv4. You need to modify the way best path is = computed. RTC, it's just putting an ORF ;) but without modifying best = path computation, we are just filtering the RIB-OUT. We can guess this = in your document, but imho this is not clearly explained. So what is = your approach here : - 1) using ADD-PATH "export all" in addition to RTC, so all routes are = putted in RIB-OUT then filtered towards PE by the RR based on the RT-ORF = ? - 2) modify the best path mechanism, create a per peer/peer-group path = eligible group (based on RTC infos), then do ADDPATH to export all paths = or some paths inside this group ? - 3) Something else ? Vinod# There is another version of the draft clearly mentioning these = scenarios in detail and I did mention this in email to Robert yesterday. = There is no best path calculation when using RT constrain. The RR just = picks the number of paths that match a given RT and advertise this to = the PE. So there would be no advantage in exporting all paths to the = RIB-OUT and then filtering prefixes/paths based on RT-ORF. The ideal = approach would instead be to create a per peer-group based model where = appropriate RT paths are only announced. The best path calculation is = only performed when an RR specific RT is announced. I had emailed this = yesterday, wherein a PE can signal an RT that is allocated to a given = set of RR(s), and the RR(s) just announce the best path for all prefixes = ir-respective of whether an RT is attached or not.=20 Another point, RTC is a complex BGP machinery, new AFI/SAFI, new way to = propagate this AFI/SAFI ... But here in fact you just need a point to = point mechanism, why not using RT based ORF, or simply a BGP standard = community based ORF ? If your ASBRs are marking routes using a special = CT (normal 32bits community), PE can choose this ASBR by just signalling = a CT based ORF to the RR (in combination with ADD-PATH) ?. So there is = nothing new to implement (except CT based ORF, but ORF idea is globally = already existing). Then you have to take into account that your ingress router need to = receive routes other than ASBR routes, so your mechanism must not = prevent that. If you are using RTC, you will receive only routes = matching your RT, potentially "internal" routes will not be received = anymore if you don't marked them with an RT imported by all your = routers. Vinod# Standard communities are already used for various purposes such = as filtering which customer routes get installed where and so on.... and = we did not want to dilute this by using standard communities for another = whole new purpose. The intent of this proposal is to leverage existing = machinery - RT and RT constrain exists in all code and deployments. We = ensure that the PE router will receive all routes other than routes = matching the RT, and this is done by allotting an RT per RR as I = mentioned in my previous emails. Each PE just needs to signal these RR = specific RTs or an RR specific RT to get the best path for all other = prefixes other than the interested RT alone. Therefore there never be a = situation where a PE will be starved of routing information if ASBRs = that match the RTs signalled via RTC lose visibility to any prefixes. Keep in mind that this proposal can work with existing machinery as well = i.e. if ADD-PATH is yet to be supported on PEs. In the event of PEs not = supporting ADD-PATH, the RR would only send a single path per RT that = gets signalled.=20 Let me know your thought, Best Regards, Stephane =20 *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et = peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only = for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et = peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only = for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* From ilya@nobulus.com Wed Jun 8 07:13:59 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16C021F8576 for ; Wed, 8 Jun 2011 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-NgpX7ezITC for ; Wed, 8 Jun 2011 07:13:59 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5CD21F850E for ; Wed, 8 Jun 2011 07:13:58 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id CDC9017391; Wed, 8 Jun 2011 16:13:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id F9N4aswm3gfJ; Wed, 8 Jun 2011 16:13:54 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:5197:4b68:4e63:cdd8]) by nobulus.com (Postfix) with ESMTPA id 5A8BC1743C; Wed, 8 Jun 2011 16:13:51 +0200 (CEST) Message-ID: <166EA90143404A4CB7D7BC62D578B963@hnivarlas1> From: "iLya" To: "Vinod Joseph" , References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> Date: Wed, 8 Jun 2011 16:13:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org, Gaurav.Thareja@colt.net, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Laurent.Lavallee@sns.bskyb.com Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:14:00 -0000 -------------------------------------------------- > Robert, > > But the fact of running SPF on behalf of a PE does not scale in a large > carrier environment, it translates to 'burning" the RR to keep up to every > single change in the network and to calculate best path to ASBRs :-) Vinod, we've already shown multiple times that calculating SPF for N sources to K destinations can be done using single SPF run instead of N runs. Please check earlier discussion on ORR. Kind regards, iLya From vjoseph@juniper.net Wed Jun 8 07:15:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A302F21F85B0 for ; Wed, 8 Jun 2011 07:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.616 X-Spam-Level: X-Spam-Status: No, score=-3.616 tagged_above=-999 required=5 tests=[AWL=-1.796, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_21=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5UwaNUXFPvA for ; Wed, 8 Jun 2011 07:15:54 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 04ABE21F85A9 for ; Wed, 8 Jun 2011 07:15:46 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTe+EEpEGO06065uKHW1Hg6VkvH//Hq1O@postini.com; Wed, 08 Jun 2011 07:15:53 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 07:13:29 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 15:13:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 15:13:25 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C069970FE@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAKG95AAB7/C6AAAQPyYAABiCyQAAC9IDAAAKjLQAAAZ9mwAAAQopA= References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1><4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC35 56A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970E2@emailemea4.jnpr.net> <15908_1307541921_4DEF81A1_15908_25798_1_4FC3556A36EE3646A09DAA60429F5335067BBAF6@PUEXCBL0.nanterre.francetelecom.fr> <90D18849576F6C41A6178B62DECAFD0F1BBDD29B@emailemea4.jnpr.net> From: Vinod Joseph To: Vinod Joseph , , X-OriginalArrivalTime: 08 Jun 2011 14:13:27.0282 (UTC) FILETIME=[3C646520:01CC25E6] Cc: idr@ietf.org, "Thareja, Gaurav" , Amit Khopkar , Chintan.Shah@colt.net, laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:15:55 -0000 Stephane, Changing BGP path computation is something we do not propose or prefer, = having the RR doing a whole lot of work on running SPF instances in a = large scale deployment just does not scale. It simply defies logic, = having an RR to stay tuned to each and every IGP change in a network = with 100/1000's of PEs, and re-run best-path calculation and = re-advertise a new exit for hot potato routing - seems very interesting = indeed. From trying to solve a problem, this would only introduce a new = set of problems for an operator to handle :-).=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Vinod Joseph=20 Sent: 08 June 2011 15:07 To: stephane.litkowski@orange-ftgroup.com; raszuk@cisco.com Cc: idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Subject: RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Yes, version 0.1 of this draft will have more detail case studies taking = in the feedback that has been received from all on the list. Stay tuned for the next version shortly. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com]=20 Sent: 08 June 2011 15:05 To: Vinod Joseph; raszuk@cisco.com Cc: idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Subject: RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Yes for me you have to use ADD path in addition to RTC to make it = working or change the BGP best path computation. But you are mentionning : "use ADD-PATH for announcing not just the best = path but all paths that match a given RT" It is imo possible to do it, ADD PATH is just a transport mechanism but = doesn't presume on how path are selected. But today, the way you need is not described in = draft-uttaro-idr-add-paths-guidelines (export n paths matching some = attributes), so an update might be needed ... Best Regards, Stephane -----Message d'origine----- De : Vinod Joseph [mailto:vjoseph@juniper.net]=20 Envoy=E9 : mercredi 8 juin 2011 15:38 =C0 : LITKOWSKI Stephane DTF/DERX; raszuk@cisco.com Cc : idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Objet : RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Inline -=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com] Sent: 08 June 2011 14:33 To: Vinod Joseph; raszuk@cisco.com Cc: idr@ietf.org; laurent.lavallee@sns.bskyb.com; Amit Khopkar; = Chintan.Shah@colt.net; Thareja, Gaurav Subject: RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Thanks for the feedback. Regarding RTC behavior, I don't agree of your interpretation of the way = it works, you said : "There is no best path calculation when using RT = constrain. The RR just picks the number of paths that match a given RT = and advertise this to the PE." Maybe I'm wrong, but I hope Robert will correct us as he is one of = people who defined RTC :) For me, RTC doesn't change anything to the way = BGP is globally working. RTC was designed to work for VPNs (first IPv4 = but now it can be used for all VPN types). RTC is just a way to signal = an interrest for a BGP speaker for a specific set of VPN prefixes = matching some RTs (with end to end possibility to propagate it). This = signalling will lead for the peer who received the RT NLRI to install a = per peer ORF. And imo that's all. So if you take this case (VPN) : PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT2 RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 =09 RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT1 RR1 still compute best path per VPN prefix (in your case it will be IPv4 = but it doesn't really matter). RD1:X/Y label z -> Path2 is best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 will advertise these best path to the peers, especially PE1, = but it has an ORF for PE1 which match only RT1, so only RD2:A/B and = RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the = community. What I mean by this, is that if you consider your case (IPv4), you will = have this : PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked with = RT1 and ASBR2 marked with RT2. PE1 will signal his interrested for RT1 and RT2. RR1 owns all IPv4 path from ASBRs, if we consider only one prefix X/Y = received from all the ASBRs, we have this : X/Y Path 1 -> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=3DASBR2 (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=3DASBR3 (IGP cost c), LP 100, ASPATH c, RT3 ... Path x -> NH=3DASBRx (IGP cost x), LP 100, ASPATH x, RTx RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 peer. RR1 selects best path for all prefixes, and so for X/Y, it will choose = one path, the best for him, based on his own criteria. So if it selects = for example Path3 as best, no path will be exported to PE1 :( Vinod# So what are proposing is: Use ADD-PATH for announcing not just = the best path but all paths that match a given RT. So in your example, = RR1 will not do a best path calc, and instead advertise Path1 and Path2 = which match RT1 and RT2. Otherwise we are not adding any value here :-) All, pls correct me if I'm wrong. Thanks, =09 -----Message d'origine----- De : Vinod Joseph [mailto:vjoseph@juniper.net] Envoy=E9 : mercredi 8 = juin 2011 15:01 =C0 : LITKOWSKI Stephane DTF/DERX Cc : idr@ietf.org; = laurent.lavallee@sns.bskyb.com; Amit Khopkar; Chintan.Shah@colt.net; = Thareja, Gaurav Objet : RE: Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Hi Stephane, Comments inline as Vinod# Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: stephane.litkowski@orange-ftgroup.com = [mailto:stephane.litkowski@orange-ftgroup.com] Sent: 08 June 2011 13:25 To: Vinod Joseph Cc: idr@ietf.org Subject: Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Hi Vinod, Some comments your the draft, I followed quickly all the discussions on = the subject on this mailing list but I have some questions more oriented = on how your system is explained in your document. I understand globally your idea, and I agree with Robert on the fact = that your draft is not proposing an optimal route-reflection but more an = "ingress preference-based" route-reflection. I understand your = explanation about what is behind the word "optimal" but generally = optimal is always shortest IGP :) otherwise this is more preference = based routing. Vinod# I am open to suggestions as you mentioned to changed the word = "optimal" to something else - if that helps. Carriers do define optimal = as being the closest IGP next-hop and this scheme does permit that to be = achieved using preferences indicated via RT Constrain. As you mention, = it moves one step further in permitting preference based routing (if you = like). Do keep in mind that this proposal does use the IGP metric as the = tie breaker in any case. For instance if a BGP speaker indicates a = preference for RT:X, and if RT:X has 4 paths, which get advertised by = the RR to the PE - Then the PE under normal conditions will choose the = NH with the closest IGP metric anyways.=20 To go more deeper in your text, in the =A75.2, you are talking about = "The objective here is to ensure that the "best path" based on the = shortest IGP metric from each PE to an ASBR is announced by the RR.". I = don't really agree on that, because your ingress router is able to = choose the paths that will be given to him by the RR using the RT = mechanism. So it could , or could not be the shortest IGP metric path = (the operator is choosing by himself). So If my understanding of your = system is good, imo a rephrasing could be necessary to explain the exact = goal/possibilities of your system. I agree that you can achieve hot = potatoe routing with your system, but it is just a subcase of a more = global approach. Vinod# Yes. But Like I mentioned the tie breaker when multiple paths are = announced to a PE is the shortest IGP metric. Therefore if the operator = decides that he only wants a set of ASBRs chosen for traffic exit - the = choice within those set of paths will always be the closest ASBR. Then you propose to use RT Constraint for IPv4 AFI/SAFI, as mentionned = by Robert, today RTC is not done per AFI/SAFI, so you will have to deal = with this and not interfer with current VPNs deployed (especially if you = are mixing IPv4/VPNv4 on RRs), it's not blocking but operator must be = aware of this when deploying your solution. Moreover you are not using basic RTC like we do for VPNv4, because you = need to modify the RR behavior to be able to compute "best path" per = peer or per peer-group : this is not done today with current RTC. RTC in = VPNv4 is working fine because of unicity of prefixes ensured by RD, but = this is not the case for IPv4. You need to modify the way best path is = computed. RTC, it's just putting an ORF ;) but without modifying best = path computation, we are just filtering the RIB-OUT. We can guess this = in your document, but imho this is not clearly explained. So what is = your approach here : - 1) using ADD-PATH "export all" in addition to RTC, so all routes are = putted in RIB-OUT then filtered towards PE by the RR based on the RT-ORF = ? - 2) modify the best path mechanism, create a per peer/peer-group path = eligible group (based on RTC infos), then do ADDPATH to export all paths = or some paths inside this group ? - 3) Something else ? Vinod# There is another version of the draft clearly mentioning these = scenarios in detail and I did mention this in email to Robert yesterday. = There is no best path calculation when using RT constrain. The RR just = picks the number of paths that match a given RT and advertise this to = the PE. So there would be no advantage in exporting all paths to the = RIB-OUT and then filtering prefixes/paths based on RT-ORF. The ideal = approach would instead be to create a per peer-group based model where = appropriate RT paths are only announced. The best path calculation is = only performed when an RR specific RT is announced. I had emailed this = yesterday, wherein a PE can signal an RT that is allocated to a given = set of RR(s), and the RR(s) just announce the best path for all prefixes = ir-respective of whether an RT is attached or not.=20 Another point, RTC is a complex BGP machinery, new AFI/SAFI, new way to = propagate this AFI/SAFI ... But here in fact you just need a point to = point mechanism, why not using RT based ORF, or simply a BGP standard = community based ORF ? If your ASBRs are marking routes using a special = CT (normal 32bits community), PE can choose this ASBR by just signalling = a CT based ORF to the RR (in combination with ADD-PATH) ?. So there is = nothing new to implement (except CT based ORF, but ORF idea is globally = already existing). Then you have to take into account that your ingress router need to = receive routes other than ASBR routes, so your mechanism must not = prevent that. If you are using RTC, you will receive only routes = matching your RT, potentially "internal" routes will not be received = anymore if you don't marked them with an RT imported by all your = routers. Vinod# Standard communities are already used for various purposes such = as filtering which customer routes get installed where and so on.... and = we did not want to dilute this by using standard communities for another = whole new purpose. The intent of this proposal is to leverage existing = machinery - RT and RT constrain exists in all code and deployments. We = ensure that the PE router will receive all routes other than routes = matching the RT, and this is done by allotting an RT per RR as I = mentioned in my previous emails. Each PE just needs to signal these RR = specific RTs or an RR specific RT to get the best path for all other = prefixes other than the interested RT alone. Therefore there never be a = situation where a PE will be starved of routing information if ASBRs = that match the RTs signalled via RTC lose visibility to any prefixes. Keep in mind that this proposal can work with existing machinery as well = i.e. if ADD-PATH is yet to be supported on PEs. In the event of PEs not = supporting ADD-PATH, the RR would only send a single path per RT that = gets signalled.=20 Let me know your thought, Best Regards, Stephane =20 *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et = peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only = for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et = peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only = for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* *************************************************************************= ******* IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) = mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, = veuillez immediatement le signaler a l expediteur et effacer ce message = et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout = virus. IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. *************************************************************************= ******* From stephane.litkowski@orange-ftgroup.com Wed Jun 8 07:19:56 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A921F85E1 for ; Wed, 8 Jun 2011 07:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.442 X-Spam-Level: X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[AWL=2.090, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_24=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L94Ks-jGFnrY for ; Wed, 8 Jun 2011 07:19:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 110DB21F85DF for ; Wed, 8 Jun 2011 07:19:52 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 6D58B190835; Wed, 8 Jun 2011 16:19:51 +0200 (CEST) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 4C0D638403A; Wed, 8 Jun 2011 16:19:51 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jun 2011 16:19:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 16:19:50 +0200 Message-ID: <13616_1307542791_4DEF8507_13616_81260_1_4FC3556A36EE3646A09DAA60429F5335067BBB17@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4DEF791B.6090500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: Acwl4BYXTwjIsFyJS8ehSa6aVJ1qkwABiIjw References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net><4DEF2027.5080605@cisco.com><5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> From: To: , "Vinod Joseph" X-OriginalArrivalTime: 08 Jun 2011 14:19:51.0422 (UTC) FILETIME=[215B81E0:01CC25E7] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.8.132718 Cc: idr@ietf.org, Gaurav.Thareja@colt.net, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Laurent.Lavallee@sns.bskyb.com Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:19:56 -0000 Robert, I agree with your approach.=20 Vinod, Today ORR/VRR fits well for hot potatoe routing. SPFs are not an issue (gen= erally you will not run it per PE, but more per PoP) and RR are more and mo= re powerful computers. For preference based routing, like in your solution, I can ask you this que= stion, why do you want to configure your preference on the PE ? It could be= configured on the RR and in this case, there is no more signalling need :)= It's a static "backbone" configuration (no need to change it every day). I= n the case, as Robert mentionned, RS solution already permits the preferenc= e based routing for a group a peers. The main question is what is the benef= it to configure the preference on the PE rather than the RR ? =20 Regards, -----Message d'origine----- De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Rober= t Raszuk Envoy=E9 : mercredi 8 juin 2011 15:29 =C0 : Vinod Joseph Cc : idr@ietf.org; Laurent.Lavallee@sns.bskyb.com; Amit.Khopkar@sns.bskyb.c= om; Chintan.Shah@colt.net; Gaurav.Thareja@colt.net Objet : Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection Vinod, In contrast using my proposal you do not to single touch any PE or any ASBR= as what the default requirement for hot potato routing calls is the shorte= st IGP exit. And that is computed automatically without any RTs, any metric= s or even without need for any BGP protocol extension. Only in the event of operator wishing to overwrite the IGP shortest exist c= hoice he may on a case by case basis use a manual policy. In fact if you follow route server space (which can equally well be applica= ble to the current discussion) such policy preference of not sending some p= aths to some clients can be realized today already by dynamic community bas= ed instruction send from client to a route server in the shipping code. Com= pletely no need to mess with any additional signaling is necessary. Especia= lly if you are talking about 1-10 preference levels. In RS such solution mu= st scale at min on 1-1000 range :). So to summarize I still see no practical case for your proposal to progress= it any further. Cheers, R. > I would look at this way Robert. An operator may plan to allot a set=20 > of RT values lets say (1-10) for a given POP/Region. The proposal=20 > specifies the need for the implementation to support RT values as=20 > ranges as well. So each PE in a region can just include a range of=20 > RTs, and this may include all or near to complete RT values that may=20 > be allotted in a POP. So when a new ASBR is added, all you need is the=20 > ASBR to have the appropriate RT used. > > In contrast, you would need to re-engineer each PE to have a new=20 > metric (administrative) towards the new ASBR. So in effect every PE=20 > interested in that ASBR needs re-calculation (on what metric is to be=20 > used and whether this ASBR is going to be the primary path or backup=20 > and so on) and re-configuration. > > Regards > > Vinod Joseph Professional Services - Service Provider Europe Juniper=20 > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net > > > > > -----Original Message----- From: Robert Raszuk=20 > [mailto:raszuk@cisco.com] Sent: 08 June 2011 08:09 To: Vinod Joseph > Cc: Amit.Khopkar@sns.bskyb.com; ilya@nobulus.com; idr@ietf.org;=20 > Laurent.Lavallee@sns.bskyb.com; Chintan.Shah@colt.net;=20 > Gaurav.Thareja@colt.net Subject: Re: [Idr] more on=20 > draft-vinod-lavallee-bgp-optimal-route-reflection > > Vinod, > >> PEs only signal interest via RT constrain and do not need to attach=20 >> RTs to their local prefixes. > > If PEs are signaling their route preference interest via RT constrain=20 > I would assume they would have to be configured with those RTs ahead=20 > of time as well. > > If not how would the PE know what to signal in RT constrain towards=20 > the RRs ? > > Thx, R. > > > >> Further elaborating on the amount of configurations required in this=20 >> draft vs the other proposals. >> >> Only ASBRs need to be configured with Route targets when advertised=20 >> to the RRs, and I am sure ASBRs are much fewer in number to PEs. The=20 >> PEs only signal interest via RT constrain and do not need to attach=20 >> RTs to their local prefixes. The reason: In most cases PE announced=20 >> customer prefixes can be controlled using standard BGP methods, if=20 >> these PE announced prefixes are not needed on an ASBR for some=20 >> special reason. >> >> On the contrary, the other solution needs every PE to ASBR pair=20 >> mapped with an administrative cost in cases where the IGP is not=20 >> preferred for use. If you have situations where each PE or groups of=20 >> PEs have diverse outbound traffic flow requirements, you would end up=20 >> having to manually setup potentially huge number of PE+ASBR pairs. In=20 >> the event of a new ASBR introduced in the network, all PEs that need=20 >> to use this ASBR as a primary exit point will need reconfiguration.=20 >> Using RT, only the ASBR will need to be configured to advertise its=20 >> paths with an additional Route target that matches a given PEs=20 >> preference - HENCE SINGLE TOUCH POINT! >> >> Regards >> >> Vinod Joseph Sent from my Blackberry Professional Services - >> Service Provider Europe, UK& Ireland Juniper Networks, Inc. +44 >> 7500 835 876 E: vjoseph@juniper.net >> >> >> >> >> ----- Original Message ----- From: Vinod Joseph To: >> raszuk@cisco.com; Amit=20 >> Khopkar Cc: iLya;=20 >> idr@ietf.org; Laurent=20 >> Lavallee Sent: Tue Jun 07 >> 22:32:03 2011 Subject: RE: [Idr] more on=20 >> draft-vinod-lavallee-bgp-optimal-route-reflection >> >> Robert, >> >> There has been some amount of confusion in regard to BGP speakers=20 >> will handle traffic in the event of prefixes not being available on=20 >> ASBRs that match the RT interest from a PEs perspective. Let me=20 >> clarify this here: >> >> -> Let us assume that there are 10 ASBRs in a network with two >> RRs (RR1 and RR2) and each ASBR has an RT for its prefixes, and PE1=20 >> has expressed interest in two RTs - lets say "A" and "B"(two ASBRs).=20 >> The RR would announce prefixes for these two ASBRs only to the PE,=20 >> therefore in the event of prefixes not being available at these two=20 >> ASBRs - traffic may be blackholed even though there are 8 other ASBRs=20 >> available. The draft clearly mentions that each RR can be allotted an=20 >> RR specific RT. So lets say RR1 has an RT of X and >> RR2 has Y. The PE1 can announce interest in RT "X" and RT "Y" in=20 >> addition to "A" and "B". This is a common deployment where, RR1 and >> RR2 will both announce prefixes that match "A" and "B" plus the best=20 >> path for all prefixes that it is aware of (Prefixes with RT extended=20 >> communities and prefixes that may be announced without RT extended=20 >> community). This will ensure that PE1 receives 2 additional paths=20 >> from RR1 and RR2 which can be used as backup in the event of prefixes=20 >> not being available from RT "A" and "B". This will ensure that=20 >> traffic will never be black-holed at all (until viable paths exist). >> >> -> Whether a network entity or local is a matter of how much >> administrative overhead vs. flexibility can be achieved. In the case=20 >> of the NH draft, each PE needs to be configured with an=20 >> administrative distance to each ASBR - if we need to achieve=20 >> something similar to what can be achieved by using RTs. This can be=20 >> complex, since we would end up calculating each pair (PE-ASBR) in=20 >> addition to traffic flows needed to put in values. On the contrary=20 >> use of RTs is nothing new for operators. Using appropriate RTs would=20 >> be the only step involved in receiving ASBR paths. >> Addition of new paths, means - just adding another RT interest or=20 >> removing it etc and does not involve re-engineering metrics. >> >> -> RT uses existing BGP machinery, therefore an operator does >> not need to worry about the support of a new capability. >> >> -> This solution proposes a scheme of announcing affinities, even >> in the case of ADD-PATH not being supported on PEs - which is an=20 >> advantage. So a PE can just indicate an RT that matches an ASBR that=20 >> is closest or administratively preferred and still get that path=20 >> announced by the RR. In addition RR specific RTs (as mentioned >> above) can provide backup in the event of the preferred ASBR losing=20 >> prefixes or going offline. >> >> -> De-coupling the RR from path selection through intelligent >> requests through affinities can certainly reduce the overhead on the=20 >> RR + the churn caused on the RR due to SPF runs. >> >> -> It is the ease of adoption - since RT has been deployed for a >> while now which makes it simpler. >> >> A updated version (01) of the draft elaborating some of these=20 >> scenarios in large detail will be released shortly. >> >> Regards >> >> Vinod Joseph Professional Services - Service Provider EMEA Juniper=20 >> Networks M: +44 (0) 7500 835 876 E: vjoseph@juniper.net >> >> >> >> >> -----Original Message----- From: Robert Raszuk=20 >> [mailto:raszuk@cisco.com] Sent: 07 June 2011 17:25 To: Amit Khopkar=20 >> Cc: iLya; Vinod Joseph; idr@ietf.org; Laurent Lavallee >> Subject: Re: [Idr] more on >> draft-vinod-lavallee-bgp-optimal-route-reflection >> >> Hi Amit, >> >>> 3. there are two approaches to resolve this a. let the route=20 >>> reflector make a decision for every PE based on some criteria (IGP=20 >>> metric in your draft) b. take the RR out of the route selection=20 >>> process (one of the main reasons for existence of >>> ADD-PATH) but in a scalable manner >> >> Since Chintan is also apparently in the same assumption let me=20 >> reiterate that base ORR IDR WG draft can use IGP metric or angular=20 >> distance approximation techniques to select optimal paths. >> >> Now if optimal for an operator means to use his other criteria the=20 >> NH-SAFI draft Ilya and I wrote comes handy as "metric" which PE=20 >> replies to RR is just a number. Yes it could be related to IGP view=20 >> of PE to such next hop, but equally well it can be related to=20 >> operator's local policy. >> >> Such local policy needs to be configured and expressed somehow. >> Your draft recommends configuring RT to match what said ASBRs would=20 >> use in route marking what clearly is more complex then allocating=20 >> local value as local value does not require a correlation with any=20 >> other network entity. That seems to be a difference you are not=20 >> seeing. >> >> The bottom line IDR WG draft + draft-varlashkin-bgp-nh-cost already=20 >> address all possible scenarios which you may need by using your=20 >> draft. >> >> If there is something in your draft which the above set is missing=20 >> and which by using the above two drafts could not be accomplished=20 >> please clearly explain. >> >> Many thx, R. > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From raszuk@cisco.com Wed Jun 8 07:22:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE5021F85FE for ; Wed, 8 Jun 2011 07:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVv3X1sjRKw9 for ; Wed, 8 Jun 2011 07:22:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6061E21F85FC for ; Wed, 8 Jun 2011 07:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=852; q=dns/txt; s=iport; t=1307542952; x=1308752552; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4O6Kq9AeUVYBsUhC/751T3fqgnqEgkv/xblwEpnY3q4=; b=liISjifWDA8n0I+u6bJErHQo+vZ8Sg1XZnPI5TEOgoNRlnv6giG/3GUB +G4QwIyp1XN5Ki4hIGxREB+lfJ2Jk9SoIZnHLPJ7rbw9aO4cMTUP3KnIA 3bqFk0KQXI4NxvICmtY7S2mpUUqO2fD6L9oBL43abzJMz+LIK6Ewf2TT3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADeF702rRDoG/2dsb2JhbABThEqhZ3eIcaBTgwAPAYoAkG6BK4NugQoEkRuETYsA X-IronPort-AV: E=Sophos;i="4.65,339,1304294400"; d="scan'208";a="461894814" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 08 Jun 2011 14:22:23 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p58EMLRx016610; Wed, 8 Jun 2011 14:22:22 GMT Message-ID: <4DEF859B.4030005@cisco.com> Date: Wed, 08 Jun 2011 16:22:19 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:22:39 -0000 Vinod, What does not scale and results in 'burning' the RR in your implementation works very well in other implementations in large carrier environments. Moreover it is deployed today as part of LFA code. I think it may be better if you consult your IGP developers before voicing such statements on the list. However I am happy that everyone already participating in this thread had a chance to hear directly from you that running few more instances of SPF (for example one per POP) is at all any measurable issue for you. Thank you for clarifying this for us. Cheers, R. > But the fact of running SPF on behalf of a PE does not scale in a > large carrier environment, it translates to 'burning" the RR to keep > up to every single change in the network and to calculate best path > to ASBRs :-) Regards > > Vinod Joseph From rjs@rob.sh Wed Jun 8 07:44:48 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB9821F8441 for ; Wed, 8 Jun 2011 07:44:48 -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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI-9r7dQQyaF for ; Wed, 8 Jun 2011 07:44:47 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB821F843E for ; Wed, 8 Jun 2011 07:44:44 -0700 (PDT) Received: from [93.97.180.64] (helo=latte.config) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1QUJzL-0007Cm-27; Wed, 08 Jun 2011 15:44:07 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> Date: Wed, 8 Jun 2011 15:44:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <508F2C32-DB1D-49AE-A23F-18F835DD5666@rob.sh> References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> To: Vinod Joseph X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, raszuk@cisco.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:44:48 -0000 On 8 Jun 2011, at 14:33, Vinod Joseph wrote: > Robert, >=20 > But the fact of running SPF on behalf of a PE does not scale in a = large carrier environment, it translates to 'burning" the RR to keep up = to every single change in the network and to calculate best path to = ASBRs :-) Hi Vinod, I have sent mails to the IDR list regarding to similar matters = previously, and whilst I've reviewed your draft, I'd like to pick up on = this comment in particular rather than the specifics of how it is = intended operate. At some point _somewhere_ in the network we have to expend additional = resource to be able to achieve the result of (more) optimal route = reflection - this either has to be on the RR by running some best path = selection algorithm that takes into account the position of the PE = within a topology, or it has to be giving the PE a number of paths that = it can choose from to be able to make the best selection. (In this case PE refers to some arbitrary edge device within the = topology that receives prefixes via BGP). The following should be noted: 1. The approach of limiting the number of paths that are advertised to = the PE, however it is achieved, does not come for free - there is still = resource expenditure on the RR to filter outgoing advertisements based = on the Route Targets that the PE has advertised to it. There is also = some resource consumption to measure this (albeit relatively static) = RT-database on the PE itself. Now, AIUI from discussions regarding RTC = with various IDR WG members, this practice is relatively lightweight for = the RR - however, the key point here is it that such path filtering is = not free in terms of CPU. (We do, however, save some CPU by not having = to transmit the UPDATE). 2. Advertising multiple paths to the PE places additional load on the = PE, which now has more paths over which it must iterate when making a = best path selection. Of course, there is a limit to the size of this = problem through limiting the number of additional paths to some = arbitrary value of N. However, comparing this to an ORR solution where = we have a single best path advertised between the=20 RR and PE - there is still some load that is incurred in best path = selection. We also have further RIB resource allocation on the PE to = store these paths. 3. I find the assertion 'running SPF on behalf of a PE does not scale in = a large carrier environment' to be very interesting. One of the points = that I've made multiple times on the subject of ORR relates particularly = to the scenario where the RR is _not_ in the forwarding path. At this = point, we have no need to constrain the resources that are available on = this device to anything that is available as a "router". All this device = has to be is a computer that is able to run the BGP best path selection = algorithm. In addition, we can scale this relatively easily (assuming = the software scales to it), since in the case where we have the RR out = of the forwarding path, and require some more optimal route selection, = it is typically centralised within most architectures. Therefore, we = have the problem that we just need to scale some processing power = centrally. I think this scales quite nicely, and actually gives = significant advantage that the CPU being used for this task is dedicated = to it. 4. With both approaches, there is some penalty incurred in terms of = one-off configuration. With the WG draft, we either need to specify our = angular positions for PEs (somewhat complex IMHO), or we need to define = some groups which we consider valid for the same ORR decision to be = made. In your approach, we need to configure each PE that advertises = routes into the network with an ingress RT, in addition, we need to = configure each client with an ordered set of RTs that indicate which = prefixes we then want to have advertised to us. =46rom an operational = overhead point of view, of course the latter is heavier. In terms of = operational complexity, this will of course depend on your operational = teams - but my concern with having an RT distributed to each PE is that = this problem is no longer restricted to the RR where the "right" route = is not being learnt by the PE in question - but rather now need = verification that the RT membership information is being advertised = correctly by the RR-C to the RR, and that the RR is performing the right = best path selection and filtering. The key point here is that we have to expend resource somewhere in the = network "system" to achieve the more optimal path being received by a = PE. I would be interested to see any figures comparing the resource = utilisation between the cases, as it seems like you are asserting that = the WG draft incurs more overhead (ignoring the operational complexity). = I also encourage you to review the discussions about more efficient = mechanisms to perform SPF that have been mentioned in discussions of = route reflection previously. Kind regards, r. From Chintan.Shah@colt.net Wed Jun 8 08:05:19 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFD321F854F for ; Wed, 8 Jun 2011 08:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGDujr6DmBlF for ; Wed, 8 Jun 2011 08:05:18 -0700 (PDT) Received: from lonmgw01.colt-telecom.com (lonmgw01.colt-telecom.com [195.110.70.112]) by ietfa.amsl.com (Postfix) with ESMTP id 6A19E21F8527 for ; Wed, 8 Jun 2011 08:05:18 -0700 (PDT) Received: from lonmgw01.colt-telecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 11FCD21C446; Wed, 8 Jun 2011 16:05:17 +0100 (BST) Received: from ULVMCTMMAI053.INTERNAL.COLT.NET (unknown [10.100.109.69]) by lonmgw01.colt-telecom.com (Postfix) with ESMTP id B459021C263; Wed, 8 Jun 2011 16:05:16 +0100 (BST) Received: from ULVMCTMMAI002.INTERNAL.COLT.NET ([fe80::d4ad:601a:c5a1:f60]) by ULVMCTMMAI053.INTERNAL.COLT.NET ([::1]) with mapi id 14.01.0289.001; Wed, 8 Jun 2011 16:05:16 +0100 From: "Shah, Chintan" To: iLya , Vinod Joseph , "raszuk@cisco.com" Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwlL2RlxAlGEy9LQf6SprB1ORCzmwAACuEAACuVnYAAA9lIsA== Date: Wed, 8 Jun 2011 15:05:15 +0000 Message-ID: <21784_1307545517_4DEF8FAC_21784_3735_1_0058F6DE932DAA41B10D5E668E09A64F22CE5697@ULVMCTMMAI002.INTERNAL.COLT.NET> References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> <166EA90143404A4CB7D7BC62D578B963@hnivarlas1> In-Reply-To: <166EA90143404A4CB7D7BC62D578B963@hnivarlas1> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.42.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "idr@ietf.org" , "Thareja, Gaurav" , "Amit.Khopkar@sns.bskyb.com" , "Laurent.Lavallee@sns.bskyb.com" Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 15:05:19 -0000 SGksDQoNCkhhdmluZyB0aGUgUlIgZG8gYSBiZXN0IHBhdGggY2FsY3VsYXRpb24gZG9lcyBub3Qg cHJvdmlkZSBhIG1lYW5zIG9mIHNlbGVjdGluZyBwcmVmZXJlbnRpYWwgcGF0aHMgYmFzZWQgb24g b3BlcmF0b3JzIHBvbGljaWVzIGFuZCBuZWVkcyBhbmQgYXMgYSBDYXJyaWVyLiBJdCB3b3VsZCAg Y2F1c2Ugc2NhbGluZyBpc3N1ZXMgd2hlbiB3ZSBzcGVhayBvZiB0aGUgc2NhbGUgb2YgYSBuZXR3 b3JrIGFuZCB0aGUgYW1vdW50IG9mIHdvcmsgdGhlIFJSIG5lZWRzIHRvIGRvLCB3aGljaCBlbmQg b2YgaXQgb25seSBnaXZlcyB1cyB0aGUgYmVzdCBJR1AgcGF0aC4NCg0KVGhlIE5IIGRyYWZ0IGlz IG9uY2UgYWdhaW4gc2VlbXMgdG8gYmUgb3ZlcmhlYWQgYXMgVmlub2QgcG9pbnRlZCBvdXQg4oCT IGVzcGVjaWFsbHkgcmUtZW5naW5lZXJpbmcgYW5kIGR1cmluZyBpbnRyb2R1Y3Rpb24gb2YgbmV3 IEFTQlJzIGV0YywgYW5kIG5lZWRzIG5ldyBjYXBhYmlsaXRpZXMuDQoJDQpJIHN0aWxsIHNlZSB0 aGUgbmV3bHkgcHJvcG9zZWQgZHJhZnQgZG9lcyBvZmZlciBmbGV4aWJpbGl0eSBuZWVkZWQgdG8g ZGVwbG95IGFuZCBtYW5hZ2UuDQoNClJlZ2FyZHMsDQpDaGludGFuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpTHlhIFttYWlsdG86aWx5YUBub2J1bHVzLmNvbV0gDQpTZW50 OiAwOCBKdW5lIDIwMTEgMTk6NDQNClRvOiBWaW5vZCBKb3NlcGg7IHJhc3p1a0BjaXNjby5jb20N CkNjOiBBbWl0Lktob3BrYXJAc25zLmJza3liLmNvbTsgaWRyQGlldGYub3JnOyBMYXVyZW50Lkxh dmFsbGVlQHNucy5ic2t5Yi5jb207IFNoYWgsIENoaW50YW47IFRoYXJlamEsIEdhdXJhdg0KU3Vi amVjdDogUmU6IFtJZHJdIG1vcmUgb24gZHJhZnQtdmlub2QtbGF2YWxsZWUtYmdwLW9wdGltYWwt cm91dGUtcmVmbGVjdGlvbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBSb2JlcnQsDQo+DQo+IEJ1dCB0aGUgZmFjdCBvZiBydW5uaW5nIFNQ RiBvbiBiZWhhbGYgb2YgYSBQRSBkb2VzIG5vdCBzY2FsZSBpbiBhIA0KPiBsYXJnZSBjYXJyaWVy IGVudmlyb25tZW50LCBpdCB0cmFuc2xhdGVzIHRvICdidXJuaW5nIiB0aGUgUlIgdG8ga2VlcCAN Cj4gdXAgdG8gZXZlcnkgc2luZ2xlIGNoYW5nZSBpbiB0aGUgbmV0d29yayBhbmQgdG8gY2FsY3Vs YXRlIGJlc3QgcGF0aCB0byANCj4gQVNCUnMgOi0pDQoNCg0KVmlub2QsDQoNCndlJ3ZlIGFscmVh ZHkgc2hvd24gbXVsdGlwbGUgdGltZXMgdGhhdCBjYWxjdWxhdGluZyBTUEYgZm9yIE4gc291cmNl cyB0byBLIGRlc3RpbmF0aW9ucyBjYW4gYmUgZG9uZSB1c2luZyBzaW5nbGUgU1BGIHJ1biBpbnN0 ZWFkIG9mIE4gcnVucy4gUGxlYXNlIGNoZWNrIGVhcmxpZXIgZGlzY3Vzc2lvbiBvbiBPUlIuDQoN CktpbmQgcmVnYXJkcywNCmlMeWENCiANCg0KCltDb2x0IERpc2NsYWltZXJdClRoZSBtZXNzYWdl IGlzIGludGVuZGVkIGZvciB0aGUgbmFtZWQgYWRkcmVzc2VlIG9ubHkgYW5kIG1heSBub3QgYmUg ZGlzY2xvc2VkCnRvIG9yIHVzZWQgYnkgYW55b25lIGVsc2UsIG5vciBtYXkgaXQgYmUgY29waWVk IGluIGFueSB3YXkuIFRoZSBjb250ZW50cyBvZgp0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBzdWJqZWN0IHRvCmxlZ2FsIHBy aXZpbGVnZS4gSWYgeW91IGFyZSBub3QgdGhlIG5hbWVkIGFkZHJlc3NlZSBhbmQvb3IgaGF2ZSBy ZWNlaXZlZCB0aGlzCm1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBhZHZpc2UgdXMgYnkgZS1tYWls aW5nIGFidXNlQGNvbHQubmV0IGFuZCBkZWxldGUgdGhlCm1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyB3aXRob3V0IHJldGFpbmluZyBhbnkgY29waWVzLiBJbnRlcm5ldApjb21tdW5pY2F0aW9u cyBhcmUgbm90IHNlY3VyZSBhbmQgQ29sdCBkb2VzIG5vdCBhY2NlcHQgcmVzcG9uc2liaWxpdHkg Zm9yIHRoaXMKbWVzc2FnZSwgaXRzIGNvbnRlbnRzIG5vciByZXNwb25zaWJpbGl0eSBmb3IgYW55 IHZpcnVzZXMuIE5vIGNvbnRyYWN0cyBjYW4gYmUKY3JlYXRlZCBvciB2YXJpZWQgb24gYmVoYWxm IG9mIENvbHQgVGVjaG5vbG9neSBTZXJ2aWNlcywgaXRzIHN1YnNpZGlhcmllcywKZ3JvdXAgY29t cGFuaWVzIG9yIGFmZmlsaWF0ZXMgKCJDb2x0IikgYW5kIGFueSBvdGhlciBwYXJ0eSBieSBlbWFp bApjb21tdW5pY2F0aW9ucyB1bmxlc3MgZXhwcmVzc2x5IGFncmVlZCBpbiB3cml0aW5nIHdpdGgg c3VjaCBvdGhlciBwYXJ0eS4KUGxlYXNlIG5vdGUgdGhhdCBpbmNvbWluZyBlbWFpbHMgd2lsbCBi ZSBhdXRvbWF0aWNhbGx5IHNjYW5uZWQgdG8gZWxpbWluYXRlCnBvdGVudGlhbCB2aXJ1c2VzIGFu ZCB1bnNvbGljaXRlZCBwcm9tb3Rpb25hbCBlbWFpbHMuIEZvciBtb3JlIGluZm9ybWF0aW9uCnJl ZmVyIHRvIHd3dy5jb2x0Lm5ldCBvciBjb250YWN0IHVzIG9uICs0NCgwKTIwIDczOTAgMzkwMAoK From vjoseph@juniper.net Wed Jun 8 08:06:11 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FAC11E80E2 for ; Wed, 8 Jun 2011 08:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja8HmA5EzMoZ for ; Wed, 8 Jun 2011 08:06:08 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 738A811E80D4 for ; Wed, 8 Jun 2011 08:05:57 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTe+P0yF5G58+0r7rMtjh0zJrGufkI+oo@postini.com; Wed, 08 Jun 2011 08:06:04 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 08:05:50 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 16:05:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 16:05:48 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06997135@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: Acwl6pwHE0sWh9elRRCpA/P7ycVtlAAAFJQw References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> <508F2C32-DB1D-49AE-A23F-18F835DD5666@rob.sh> From: Vinod Joseph To: Rob Shakir X-OriginalArrivalTime: 08 Jun 2011 15:05:49.0037 (UTC) FILETIME=[8D0629D0:01CC25ED] Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, raszuk@cisco.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 15:06:11 -0000 Very interesting comments indeed. These are two diverse approaches Rob. Firstly the ORR (Robert's) draft only offers best path based on the IGP. = If a preferred list of paths (lets say PE1 needs ASBR1, ASBR2, ASBR3) is = needed by a PE - Then a manual policy is needed to override this = behaviour as Robert pointed out. Let us say the network largely needs a = set of pre-defined paths as mentioned above, then you would end up = manually configuring policies on the RR(s) to reflect each requirement = of such. This is a lot of manual configurations. When using RTs: An operator may plan to allot a set of RT values let's = say (1-10) for a given POP/Region. The proposal specifies the need for = the implementation to support RT values as ranges as well. So each PE in = a region can just include a range of RTs, and this may include all or = near to complete RT values that may be allotted in a POP. So when a new = ASBR is added, all you need is the ASBR to have the appropriate RT used. = This may be easier to pre-provision rather than reflect/respond to a = change whenever it happens.=20 Having multiple paths on the PE, depending on many or how few (whatever = be the capability of the PE to handle) - improves convergence in the = event of paths going away, since there is more than a single path = available locally. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Rob Shakir [mailto:rjs@rob.sh]=20 Sent: 08 June 2011 15:45 To: Vinod Joseph Cc: raszuk@cisco.com; idr@ietf.org; Laurent.Lavallee@sns.bskyb.com; = Amit.Khopkar@sns.bskyb.com; Chintan.Shah@colt.net; = Gaurav.Thareja@colt.net Subject: Re: [Idr] more on = draft-vinod-lavallee-bgp-optimal-route-reflection On 8 Jun 2011, at 14:33, Vinod Joseph wrote: > Robert, >=20 > But the fact of running SPF on behalf of a PE does not scale in a = large carrier environment, it translates to 'burning" the RR to keep up = to every single change in the network and to calculate best path to = ASBRs :-) Hi Vinod, I have sent mails to the IDR list regarding to similar matters = previously, and whilst I've reviewed your draft, I'd like to pick up on = this comment in particular rather than the specifics of how it is = intended operate. At some point _somewhere_ in the network we have to expend additional = resource to be able to achieve the result of (more) optimal route = reflection - this either has to be on the RR by running some best path = selection algorithm that takes into account the position of the PE = within a topology, or it has to be giving the PE a number of paths that = it can choose from to be able to make the best selection. (In this case PE refers to some arbitrary edge device within the = topology that receives prefixes via BGP). The following should be noted: 1. The approach of limiting the number of paths that are advertised to = the PE, however it is achieved, does not come for free - there is still = resource expenditure on the RR to filter outgoing advertisements based = on the Route Targets that the PE has advertised to it. There is also = some resource consumption to measure this (albeit relatively static) = RT-database on the PE itself. Now, AIUI from discussions regarding RTC = with various IDR WG members, this practice is relatively lightweight for = the RR - however, the key point here is it that such path filtering is = not free in terms of CPU. (We do, however, save some CPU by not having = to transmit the UPDATE). 2. Advertising multiple paths to the PE places additional load on the = PE, which now has more paths over which it must iterate when making a = best path selection. Of course, there is a limit to the size of this = problem through limiting the number of additional paths to some = arbitrary value of N. However, comparing this to an ORR solution where = we have a single best path advertised between the=20 RR and PE - there is still some load that is incurred in best path = selection. We also have further RIB resource allocation on the PE to = store these paths. 3. I find the assertion 'running SPF on behalf of a PE does not scale in = a large carrier environment' to be very interesting. One of the points = that I've made multiple times on the subject of ORR relates particularly = to the scenario where the RR is _not_ in the forwarding path. At this = point, we have no need to constrain the resources that are available on = this device to anything that is available as a "router". All this device = has to be is a computer that is able to run the BGP best path selection = algorithm. In addition, we can scale this relatively easily (assuming = the software scales to it), since in the case where we have the RR out = of the forwarding path, and require some more optimal route selection, = it is typically centralised within most architectures. Therefore, we = have the problem that we just need to scale some processing power = centrally. I think this scales quite nicely, and actually gives = significant advantage that the CPU being used for this task is dedicated = to it. 4. With both approaches, there is some penalty incurred in terms of = one-off configuration. With the WG draft, we either need to specify our = angular positions for PEs (somewhat complex IMHO), or we need to define = some groups which we consider valid for the same ORR decision to be = made. In your approach, we need to configure each PE that advertises = routes into the network with an ingress RT, in addition, we need to = configure each client with an ordered set of RTs that indicate which = prefixes we then want to have advertised to us. From an operational = overhead point of view, of course the latter is heavier. In terms of = operational complexity, this will of course depend on your operational = teams - but my concern with having an RT distributed to each PE is that = this problem is no longer restricted to the RR where the "right" route = is not being learnt by the PE in question - but rather now need = verification that the RT membership information is being advertised = correctly by the RR-C to the RR, and that the RR is performing the right = best path selection and filtering. The key point here is that we have to expend resource somewhere in the = network "system" to achieve the more optimal path being received by a = PE. I would be interested to see any figures comparing the resource = utilisation between the cases, as it seems like you are asserting that = the WG draft incurs more overhead (ignoring the operational complexity). = I also encourage you to review the discussions about more efficient = mechanisms to perform SPF that have been mentioned in discussions of = route reflection previously. Kind regards, r. From raszuk@cisco.com Wed Jun 8 08:58:47 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561EE11E8125 for ; Wed, 8 Jun 2011 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.386 X-Spam-Level: X-Spam-Status: No, score=-10.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOhVpHPcJEg4 for ; Wed, 8 Jun 2011 08:58:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4D111E8124 for ; Wed, 8 Jun 2011 08:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1640; q=dns/txt; s=iport; t=1307548726; x=1308758326; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cxbOGs/EeqUtOZjVt9xDb3ySmeYL7M+Ow2Ht/oT6blk=; b=LrV5K8EsijbeRBj+PKK9jXvDCOJZG64Ja7dVdWcdeH6kqMFMzqRmdttg JRk/IkKmh5E5skwc16XCxCwJQ/k+mF1dyuf94seOAZnNAa3m0EEmr/s5Z c33Mgrk/UzS/Qolevd8tSw16v6z46v2jgmdH1L+hBTF4xRovacwpIW1AR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHyb702rRDoJ/2dsb2JhbABTpjF3iHGgZIMADwGabYYjBJEbhE2LAA X-IronPort-AV: E=Sophos;i="4.65,339,1304294400"; d="scan'208";a="332796977" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2011 15:58:46 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p58FwgOR030694; Wed, 8 Jun 2011 15:58:43 GMT Message-ID: <4DEF9C30.2020202@cisco.com> Date: Wed, 08 Jun 2011 17:58:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> <508F2C32-DB1D-49AE-A23F-18F835DD5666@rob.sh> <5DD781A4BE13384A900438DF0608972C06997135@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06997135@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 15:58:47 -0000 Vinod, > Firstly the ORR (Robert's) draft only offers best path based on the > IGP. If a preferred list of paths (lets say PE1 needs ASBR1, ASBR2, > ASBR3) is needed by a PE - Then a manual policy is needed to override > this behaviour as Robert pointed out. Let us say the network largely > needs a set of pre-defined paths as mentioned above, then you would > end up manually configuring policies on the RR(s) to reflect each > requirement of such. This is a lot of manual configurations. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think we have more basic problems here ... You said you have requirement to set 1-10 levels of ASBR preference on a per POP basis. Assume you have 20 POPs and each POP needs to get unique set of paths. So this "a lot of manual configuration" on RR would result assuming you want two paths to be send to each client in 40 additional lines of configuration. And this configuration stays there in the same way as it stays on your PEs. Now assume you want more then per POP .. you have 1000 PEs and want it per PE. Why not ... screw the network completely. What you do then you use peer templates which depending on the peer's policy are applied in the same manner to many peers. So if you have 1-10 exit preferences and you want to send 2 paths to each PE combination of 2 out of 10 without repetition is: 10!/(2!(10-2)!) = 45 Is 45 lines of additional configuration a lot ? I don't know about you, but I have seen production configurations of large networks and adding 45 lines of config there would be in the noise. Cheers, R. From bruno.decraene@orange-ftgroup.com Wed Jun 8 10:10:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3760421F8502 for ; Wed, 8 Jun 2011 10:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaCt3xisPlxt for ; Wed, 8 Jun 2011 10:10:03 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7697221F84FD for ; Wed, 8 Jun 2011 10:09:57 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7052C958001; Wed, 8 Jun 2011 19:17:16 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 64A867D8002; Wed, 8 Jun 2011 19:17:16 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 19:09:55 +0200 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: Wed, 8 Jun 2011 19:09:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) Thread-Index: Acwl/uL5Ntsvnz9+TGSFW4Io4TZJBQ== From: To: X-OriginalArrivalTime: 08 Jun 2011 17:09:55.0620 (UTC) FILETIME=[E3888E40:01CC25FE] Cc: idr@ietf.org Subject: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:10:06 -0000 Vinod, "draft-vinod-lavallee-bgp-optimal-route-reflection-00 Abstract This document describes procedures on providing optimal routing for IPv4 Internet traffic based on the shortest IGP metric." I would argue that currently the above draft does not provide optimal routing based on the shortest IGP metric, but rather based on Service Provider policy. I think the difference is important, especially when there is another draft on that matter. Could you please reflect this in the draft? And in the name of the draft? If the requirement is to perform optimal route reflection based on IGP metric, the data required for the computation comes from the IGP. I don't see how asking the Service Provider to configure (an ersatz of) this data again (through the configuration of RT communities & RTC routes) could be any better (simpler/more accurate/less expensive...). In the benefit of advancing on this subject, I believe we could agree on the above 2 points and close that part of the discussion. Hopefully that should clarify the relations between this draft and draft-ietf-idr-bgp-optimal-route-reflection-00. Now if your draft if about configuring policy based routing, IMO it would be interesting to discuss the following points: what data need to be configured, where does it need to be configured (e.g. PE vs RR), how hard is it for the SP to "compute" that data; why and how to propagate policy data between routers in the AS... Thanks, Regards, Bruno From vjoseph@juniper.net Wed Jun 8 10:24:52 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E3B11E80FB for ; Wed, 8 Jun 2011 10:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qahhLo8IrIv for ; Wed, 8 Jun 2011 10:24:51 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id E07BF11E80F3 for ; Wed, 8 Jun 2011 10:24:49 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTe+wYSJBO2oQpzwH0BTIj6Nx5856Qxeo@postini.com; Wed, 08 Jun 2011 10:24:51 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 10:23:59 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 18:23:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 18:23:56 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06997197@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) Thread-Index: Acwl/uL5Ntsvnz9+TGSFW4Io4TZJBQAAFC6w References: From: Vinod Joseph To: X-OriginalArrivalTime: 08 Jun 2011 17:23:57.0417 (UTC) FILETIME=[D9489590:01CC2600] Cc: idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:24:52 -0000 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: bruno.decraene@orange-ftgroup.com = [mailto:bruno.decraene@orange-ftgroup.com]=20 Sent: 08 June 2011 18:10 To: Vinod Joseph Cc: idr@ietf.org Subject: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP = vs policy based routing) Vinod, "draft-vinod-lavallee-bgp-optimal-route-reflection-00 Abstract This document describes procedures on providing optimal routing for IPv4 Internet traffic based on the shortest IGP metric." I would argue that currently the above draft does not provide optimal routing based on the shortest IGP metric, but rather based on Service Provider policy. I think the difference is important, especially when there is another draft on that matter. Could you please reflect this in the draft? And in the name of the draft? Vinod# Agreed, and this will reflect in the next version as mentioned = yesterday- since the proposal is not merely about facilitating paths = that have the shortest IGP metric only!! If the requirement is to perform optimal route reflection based on IGP metric, the data required for the computation comes from the IGP. I don't see how asking the Service Provider to configure (an ersatz of) this data again (through the configuration of RT communities & RTC routes) could be any better (simpler/more accurate/less expensive...). Vinod# So, this is about providing preferential path selection in short. = In the benefit of advancing on this subject, I believe we could agree on the above 2 points and close that part of the discussion. Hopefully that should clarify the relations between this draft and draft-ietf-idr-bgp-optimal-route-reflection-00. Now if your draft if about configuring policy based routing, IMO it would be interesting to discuss the following points: what data need to be configured, where does it need to be configured (e.g. PE vs RR), how hard is it for the SP to "compute" that data; why and how to propagate policy data between routers in the AS... Vinod# Policy driven path selection is configured on the PEs/ASBRs (BGP = speakers) using Route Targets (configured) and RT Constrain. The RR = responds with a list of paths that match the RTs indicated - it could be = a list, range or the default RT. The RR computes this information and = advertises needed information to BGP speakers. There is no propagation = needed between individual BGP speakers in the network, and is only = needed between BGP Speakers to RR. PS: In my earlier email I had indicated that we are open to suggestions = - if the name needs to reflect something else. Thanks, Regards, Bruno From internet-drafts@ietf.org Wed Jun 8 13:47:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBD01F0C3D; Wed, 8 Jun 2011 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIhOr7BmHN4L; Wed, 8 Jun 2011 13:47:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC2211E8174; Wed, 8 Jun 2011 13:47:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110608204732.21837.12076.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2011 13:47:32 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:47:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Dissemination of Flow Specification Rules for IPv6 Author(s) : Robert Raszuk Burjiz Pithawala Danny McPherson Filename : draft-ietf-idr-flow-spec-v6-00.txt Pages : 8 Date : 2011-06-02 Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-00.txt From internet-drafts@ietf.org Wed Jun 8 13:47:57 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684111F0C47; Wed, 8 Jun 2011 13:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pq+-mzQ66eJ; Wed, 8 Jun 2011 13:47:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE11F0C3E; Wed, 8 Jun 2011 13:47:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110608204756.21808.6195.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2011 13:47:56 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:47:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Enhanced Route Refresh Capability for BGP-4 Author(s) : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-00.txt Pages : 6 Date : 2011-06-02 In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate on-line, non-disruptive consistency validations of BGP routing updates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-enhanced-route-refre= sh-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-enhanced-route-refres= h-00.txt From internet-drafts@ietf.org Wed Jun 8 13:48:09 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FA41F0C4D; Wed, 8 Jun 2011 13:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77Fz0udBFNEg; Wed, 8 Jun 2011 13:48:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AAD1F0C43; Wed, 8 Jun 2011 13:48:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110608204808.21809.18575.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2011 13:48:08 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:48:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Extended Message support for BGP Author(s) : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-00.txt Pages : 5 Date : 2011-06-06 The current BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension for BGP to extend its current message size for BGP messages from 4096 octets to 65535 octets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-extended-messages-00= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-extended-messages-00.= txt From vjoseph@juniper.net Wed Jun 8 16:22:54 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A634111E8080 for ; Wed, 8 Jun 2011 16:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s2cQa6UrBoC for ; Wed, 8 Jun 2011 16:22:54 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7E75611E80D7 for ; Wed, 8 Jun 2011 16:22:47 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTfAER8DMbQQDx8KMmZtJk6WDzwAZxVga@postini.com; Wed, 08 Jun 2011 16:22:49 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Wed, 8 Jun 2011 16:21:57 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 00:21:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jun 2011 00:22:21 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C069971D4@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) Thread-Index: Acwl/uL5Ntsvnz9+TGSFW4Io4TZJBQAAFC6wAAzdTBA= References: <90D18849576F6C41A6178B62DECAFD0F1BBDD2A1@emailemea4.jnpr.net> From: Vinod Joseph To: Vinod Joseph , X-OriginalArrivalTime: 08 Jun 2011 23:21:55.0857 (UTC) FILETIME=[DB6E7010:01CC2632] Cc: idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 23:22:54 -0000 Bruno,=20 So addressing your question on the title of the draft, I hope we have = clearly communicated that the proposed draft addresses a set of given = requirements, and the next version will incorporate the proposed = suggestions and reflect a title which is of consensus to all members. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Vinod Joseph=20 Sent: 08 June 2011 18:24 To: bruno.decraene@orange-ftgroup.com Cc: idr@ietf.org Subject: RE: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest = IGP vs policy based routing) Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: bruno.decraene@orange-ftgroup.com = [mailto:bruno.decraene@orange-ftgroup.com]=20 Sent: 08 June 2011 18:10 To: Vinod Joseph Cc: idr@ietf.org Subject: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP = vs policy based routing) Vinod, "draft-vinod-lavallee-bgp-optimal-route-reflection-00 Abstract This document describes procedures on providing optimal routing for IPv4 Internet traffic based on the shortest IGP metric." I would argue that currently the above draft does not provide optimal routing based on the shortest IGP metric, but rather based on Service Provider policy. I think the difference is important, especially when there is another draft on that matter. Could you please reflect this in the draft? And in the name of the draft? Vinod# Agreed, and this will reflect in the next version as mentioned = yesterday- since the proposal is not merely about facilitating paths = that have the shortest IGP metric only!! If the requirement is to perform optimal route reflection based on IGP metric, the data required for the computation comes from the IGP. I don't see how asking the Service Provider to configure (an ersatz of) this data again (through the configuration of RT communities & RTC routes) could be any better (simpler/more accurate/less expensive...). Vinod# So, this is about providing preferential path selection in short. = In the benefit of advancing on this subject, I believe we could agree on the above 2 points and close that part of the discussion. Hopefully that should clarify the relations between this draft and draft-ietf-idr-bgp-optimal-route-reflection-00. Now if your draft if about configuring policy based routing, IMO it would be interesting to discuss the following points: what data need to be configured, where does it need to be configured (e.g. PE vs RR), how hard is it for the SP to "compute" that data; why and how to propagate policy data between routers in the AS... Vinod# Policy driven path selection is configured on the PEs/ASBRs (BGP = speakers) using Route Targets (configured) and RT Constrain. The RR = responds with a list of paths that match the RTs indicated - it could be = a list, range or the default RT. The RR computes this information and = advertises needed information to BGP speakers. There is no propagation = needed between individual BGP speakers in the network, and is only = needed between BGP Speakers to RR. PS: In my earlier email I had indicated that we are open to suggestions = - if the name needs to reflect something else. Thanks, Regards, Bruno From bruno.decraene@orange-ftgroup.com Thu Jun 9 01:10:27 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBE71F0C3B for ; Thu, 9 Jun 2011 01:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PV1s5JCSjzA for ; Thu, 9 Jun 2011 01:10:27 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id C64A01F0C45 for ; Thu, 9 Jun 2011 01:10:26 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7CB5C9B003F; Thu, 9 Jun 2011 10:07:28 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1E42A8C003A; Thu, 9 Jun 2011 10:02:59 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 10:00:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jun 2011 10:00:45 +0200 Message-ID: In-Reply-To: <5DD781A4BE13384A900438DF0608972C06997197@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) Thread-Index: Acwl/uL5Ntsvnz9+TGSFW4Io4TZJBQAAFC6wABzlI0A= References: <5DD781A4BE13384A900438DF0608972C06997197@emailemea4.jnpr.net> From: To: X-OriginalArrivalTime: 09 Jun 2011 08:00:46.0685 (UTC) FILETIME=[56D9D0D0:01CC267B] Cc: idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 08:10:28 -0000 Vinod, >Vinod, > >"draft-vinod-lavallee-bgp-optimal-route-reflection-00 > >Abstract > > This document describes procedures on providing optimal routing for > IPv4 Internet traffic based on the shortest IGP metric." > >I would argue that currently the above draft does not provide optimal >routing based on the shortest IGP metric, but rather based on Service >Provider policy. I think the difference is important, especially when >there is another draft on that matter. Could you please reflect this in >the draft? And in the name of the draft? > >Vinod# Agreed, and this will reflect in the next version as mentioned = yesterday Ok, thanks. > - since the proposal is not merely about facilitating paths that have = the shortest IGP metric only!! Hum... My point was that the draft addresses a requirement for policy / TE = routing. _Not_ for shortest IGP metric routing. You're rephrasing by = saying that the draft more or less addresses both points. So I'm not = sure how much we are in sync. >If the requirement is to perform optimal route reflection based on IGP >metric, the data required for the computation comes from the IGP. I >don't see how asking the Service Provider to configure (an ersatz of) >this data again (through the configuration of RT communities & RTC >routes) could be any better (simpler/more accurate/less expensive...). > >Vinod# So, this is about providing preferential path selection in = short. "Prefered" based on what criteria? SP policy IMO, not IGP cost. >In the benefit of advancing on this subject, I believe we could agree = on >the above 2 points and close that part of the discussion. Hopefully = that >should clarify the relations between this draft and >draft-ietf-idr-bgp-optimal-route-reflection-00. > > >Now if your draft if about configuring policy based routing, IMO it >would be interesting to discuss the following points: what data need to >be configured, where does it need to be configured (e.g. PE vs RR), how >hard is it for the SP to "compute" that data; why and how to propagate >policy data between routers in the AS... > >Vinod# Policy driven path selection is configured on the PEs/ASBRs (BGP = speakers) using Route Targets >(configured) and RT Constrain. The RR responds with a list of paths = that match the RTs indicated - it >could be a list, range or the default RT. The RR computes this = information and advertises needed >information to BGP speakers. There is no propagation needed between = individual BGP speakers in the >network, and is only needed between BGP Speakers to RR. Thanks for summarizing you solution. My intended question was more about the general problem that need to be = solved and why you picked that specific (RTC based) solution rather than = another one. e.g.: - why is the criteria for filtering configured on the PE received the = routes, rather than the RR sending the routes? There are probably some = advantages but the cost is to require an additional protocol to = communicate those criteria to the RR (that protocol being RTC in you = case). As already expressed on the list, you could define a BGP policy = directly on the RR. - on the PE sending the routes, why do you use RT extended communities = rather than a regular communities. There may be little difference in a = Greenfield scenario but in a existing network where SP use regular = communities, this requires updating the configuration of all PE, all BGP = peering policies to add an RT community in addition to the existing = community. This may have a benefit but it would be usefull to elaborate = on this benefit otherwise people will have more difficulties adopting = your idea. - why do you think RTC is the best fit for you application? RTC has been = specifically designed for the VPN application. I see significant = differences in applicability: - in VPN, PE receiving routes are already configured with import RT = policies. This is required to import routes in the relevant VRF. So for = filtering BGP routes on the RR, it makes sense to re-use that already = configured information. Even if this requires adding a new "protocol" to = it from the PE to the RR. This is not the case in your application. - in VPN, PE sending routes are already configured with a specific = export policies setting RT on routes. This is not the case in your = application as typically SP uses no RT communities. - So in short, in a VPN context, RTC make use of existing configuration = data. In the IPv4 context, such RT information is not configured and you = require the SP to configure it. IMO this is a significant difference for = the SP point of view.=20 >PS: In my earlier email I had indicated that we are open to suggestions = - if the name needs to reflect >something else. Yes IMO the name needs to reflect something else. E.g. Application of = RTC to the distribution of BGP routing TE policies in IP networks.=20 -- On a more detailed / technical level, could you also please clarify if = your document propose to _use_ RFC 4684 (RTC) or _modify/extend_ it?=20 =A7 5.3 says "It is to be noted that the "Default RT" indicates that all = prefixes/ paths even without a corresponding RT will be considered as = candidates for announcements." According to my own reading of RFC 4684, the default RTC route matches = all RT communities. It would not allow requesting routes which have not = RT community attached to them. Agreed RFC 4684 is not that specific on = this as it says "receive all VPN route " but IMO this is because it = assumes that all VPN routes have at least one RT attached on it. Thanks, Regards, Bruno From raszuk@cisco.com Thu Jun 9 01:38:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEE61F0C48 for ; Thu, 9 Jun 2011 01:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et3VCjAwgBsT for ; Thu, 9 Jun 2011 01:38:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4FB1F0C45 for ; Thu, 9 Jun 2011 01:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1330; q=dns/txt; s=iport; t=1307608715; x=1308818315; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bSh7Y5fzE3ag3RKJwIUa2zX+PtLg6LcBhk3iMigIGAo=; b=egrX0uLiEZV8DECVNdLCW7uJfaf8SVWks+wE33IUg7K7L1HovT0bTBoE KRfXpjAdb4bhMed+6Hyz2IQaKaSRtcTiUjQM3iKeek4iADRdeAMCxBZfQ bN9nHzNB9RBZAvOPLlUuQD1pdBZ8o8RbwVVKHg68pp4Ebt0o0SXeQIVGJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQHANCF8E2rRDoH/2dsb2JhbABSmAeOMneob4MIDwGbFIYjBJEqhE2LBw X-IronPort-AV: E=Sophos;i="4.65,340,1304294400"; d="scan'208";a="333359418" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2011 08:38:35 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p598cXIp000954; Thu, 9 Jun 2011 08:38:34 GMT Message-ID: <4DF0869D.5040309@cisco.com> Date: Thu, 09 Jun 2011 10:38:53 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: bruno.decraene@orange-ftgroup.com References: <5DD781A4BE13384A900438DF0608972C06997197@emailemea4.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: idr@ietf.org, vjoseph@juniper.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 08:38:36 -0000 Hello, While we are at the RTC topic ... I see even bigger issue with them defining "special RT" applied at RRs to mean send me overall best if my requested RTs are not available. That was used as the explanation on how their proposal will address the issue when non of preferred paths are available yet other non preferred paths could be used. That is more like conditional advertisement feature and I don't think we have ever intended to combine it with RTC. Thx, R. -- On a more detailed / technical level, could you also please clarify if your document propose to _use_ RFC 4684 (RTC) or _modify/extend_ it? § 5.3 says "It is to be noted that the "Default RT" indicates that all prefixes/ paths even without a corresponding RT will be considered as candidates for announcements." According to my own reading of RFC 4684, the default RTC route matches all RT communities. It would not allow requesting routes which have not RT community attached to them. Agreed RFC 4684 is not that specific on this as it says "receive all VPN route " but IMO this is because it assumes that all VPN routes have at least one RT attached on it. Thanks, Regards, Bruno _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From vjoseph@juniper.net Thu Jun 9 01:45:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE6111E807E for ; Thu, 9 Jun 2011 01:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3wuFCSEW1Nb for ; Thu, 9 Jun 2011 01:45:22 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5051F0C45 for ; Thu, 9 Jun 2011 01:45:19 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTfCIG+qBRI2pgp7XGebiXitaT4e6/uRq@postini.com; Thu, 09 Jun 2011 01:45:21 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Thu, 9 Jun 2011 01:44:50 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 09:44:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jun 2011 09:44:48 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C063BE39E@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) Thread-Index: AcwmgKJ0zAAjC4+jTJ68Hvu+Zp/4dwAANrA2 From: Vinod Joseph To: , X-OriginalArrivalTime: 09 Jun 2011 08:44:49.0155 (UTC) FILETIME=[7DE2BD30:01CC2681] Cc: gaurav.thareja@gmail.com, idr@ietf.org, Chintan.Shah@colt.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 08:45:23 -0000 This is proposed specifically to address the need of an operator to = indicate a list of preferred NHs and in addition to have the option of = an RR selected path as well. Regards Vinod Joseph Sent from my Blackberry=20 Professional Services - Service Provider Europe, UK & Ireland Juniper Networks, Inc.=20 +44 7500 835 876 E: vjoseph@juniper.net =20 ----- Original Message ----- From: Robert Raszuk To: bruno.decraene@orange-ftgroup.com = Cc: Vinod Joseph; idr@ietf.org Sent: Thu Jun 09 09:38:53 2011 Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection = (shortest IGP vs policy based routing) Hello, While we are at the RTC topic ... I see even bigger issue with them defining "special RT" applied at RRs=20 to mean send me overall best if my requested RTs are not available. That was used as the explanation on how their proposal will address the=20 issue when non of preferred paths are available yet other non preferred=20 paths could be used. That is more like conditional advertisement feature and I don't think we = have ever intended to combine it with RTC. Thx, R. -- On a more detailed / technical level, could you also please clarify if=20 your document propose to _use_ RFC 4684 (RTC) or _modify/extend_ it? =A7 5.3 says "It is to be noted that the "Default RT" indicates that all = prefixes/ paths even without a corresponding RT will be considered as=20 candidates for announcements." According to my own reading of RFC 4684, the default RTC route matches=20 all RT communities. It would not allow requesting routes which have not=20 RT community attached to them. Agreed RFC 4684 is not that specific on=20 this as it says "receive all VPN route " but IMO this is because it=20 assumes that all VPN routes have at least one RT attached on it. Thanks, Regards, Bruno _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Thu Jun 9 01:56:29 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790C521F847E for ; Thu, 9 Jun 2011 01:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk-5Ubclmzg5 for ; Thu, 9 Jun 2011 01:56:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DEC0E21F847D for ; Thu, 9 Jun 2011 01:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2627; q=dns/txt; s=iport; t=1307609788; x=1308819388; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Amux50PjoXuHlmKmcAgNPANinTuwA0D+e3Wj9nnv0ZQ=; b=U51Gtb7QeWBiYeMb9XWlIvaSIeQ2sPHqNr74ApJB93Z61eAUK6TfPnW1 hEGSG/7oyJRGhB0HtIP0LA2haHPzxnw459mBhXEVAgD18ZgScQx8ArosF 4AX9mfD9QJ3PoVi6cKJhQ/xtswys6HorfIkVLwr7mm1srEVI94cHNAL3l 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAOK8E2rRDoH/2dsb2JhbABSpjh3iHGgB4MIDwGbEoYjBJEqhE2LBw X-IronPort-AV: E=Sophos;i="4.65,340,1304294400"; d="scan'208";a="373281119" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2011 08:56:28 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p598uQsj016942; Thu, 9 Jun 2011 08:56:26 GMT Message-ID: <4DF08ACE.1000609@cisco.com> Date: Thu, 09 Jun 2011 10:56:46 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <5DD781A4BE13384A900438DF0608972C063BE39E@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C063BE39E@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 08:56:29 -0000 If you would not use RR selected paths as well how are you going to provide service to those PEs which preferred 2 paths out of 10 and those 2 paths are withdrawn. If you would use RR selected overall path always to be send to the client how are you going to enforce the client not to select such path locally as overall best ? In other words are you going to modify bgp best path selection on the client based on the attached RT extended community ? Please do answer both questions. Many thx, R. > This is proposed specifically to address the need of an operator to > indicate a list of preferred NHs and in addition to have the option > of an RR selected path as well. > > Regards > > Vinod Joseph Sent from my Blackberry Professional Services - Service > Provider Europe, UK& Ireland Juniper Networks, Inc. +44 7500 835 > 876 E: vjoseph@juniper.net > > > > > ----- Original Message ----- From: Robert Raszuk > To: > bruno.decraene@orange-ftgroup.com > Cc: Vinod Joseph; idr@ietf.org Sent: Thu Jun 09 > 09:38:53 2011 Subject: Re: [Idr] > draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs > policy based routing) > > Hello, > > While we are at the RTC topic ... > > I see even bigger issue with them defining "special RT" applied at > RRs to mean send me overall best if my requested RTs are not > available. > > That was used as the explanation on how their proposal will address > the issue when non of preferred paths are available yet other non > preferred paths could be used. > > That is more like conditional advertisement feature and I don't think > we have ever intended to combine it with RTC. > > Thx, R. > > -- On a more detailed / technical level, could you also please > clarify if your document propose to _use_ RFC 4684 (RTC) or > _modify/extend_ it? § 5.3 says "It is to be noted that the "Default > RT" indicates that all prefixes/ paths even without a corresponding > RT will be considered as candidates for announcements." According to > my own reading of RFC 4684, the default RTC route matches all RT > communities. It would not allow requesting routes which have not RT > community attached to them. Agreed RFC 4684 is not that specific on > this as it says "receive all VPN route " but IMO this is because it > assumes that all VPN routes have at least one RT attached on it. > > > Thanks, Regards, Bruno > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From raszuk@cisco.com Thu Jun 9 03:59:47 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E25228003 for ; Thu, 9 Jun 2011 03:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.42 X-Spam-Level: X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP2CrE9vP3aA for ; Thu, 9 Jun 2011 03:59:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id E708E21F852B for ; Thu, 9 Jun 2011 03:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1024; q=dns/txt; s=iport; t=1307617186; x=1308826786; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=sPkGnJXkPbrElx+sWhGY/k9+7bet20OajdJRz4B2j0A=; b=SosuHHT7Ud3CRpEmn3XDW0E8Tm5e+yypxVQlFP0PYsf/1rr6TbLsNsOr sUEa81egP0tN5LcfiaLJJauXA+hD4iGzSK3uWtUgCvdR8Z0LHDy9elQct VGrm4wkxLhDXJ+5+PG0O7OgbWlz21967fbzwkbSbaQGBHB6HzWrkjd9Eu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsGAE6n8E2rRDoG/2dsb2JhbABTmAiOMneodoMIDwGbDIYjBJEqhE2LBw X-IronPort-AV: E=Sophos;i="4.65,340,1304294400"; d="scan'208";a="373339393" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2011 10:59:46 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p59AxjWx006910 for ; Thu, 9 Jun 2011 10:59:45 GMT Message-ID: <4DF0A79D.8040500@cisco.com> Date: Thu, 09 Jun 2011 12:59:41 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <90D18849576F6C41A6178B62DECAFD0F1BBDD2A1@emailemea4.jnpr.net> <5DD781A4BE13384A900438DF0608972C069971D4@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C069971D4@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] Requirements of draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 10:59:47 -0000 Dear authors and co-authors of draft-vinod-lavallee-bgp-optimal-route-reflection, 1. I would like to ask you to clearly provide set of requirements from the point of view of PE in the point by point list your draft is attempting to solve and which must be met by any proposed solution. 2. I would like to ask to clearly state that the solution is applicable _only_ to full end to end MPLS LSP networks. In the event of network selecting to use TE-LSPs as it's forwarding plane I would like to see detailed reference to inter-area stitching solution deployed on the ABRs which avoids need for IP lookup. That description should clearly address IPv4 unicast, IPv4 multicast, IPv6 unicast and IPv6 multicast address families. 3. To put scale arguments in perspective please also indicate the scale ranges required to be possible for the solution. Number of PEs, number of required paths per PE for a given net and number of available ASBRs in the given autonomous system. Best regards, R. From raszuk@cisco.com Thu Jun 9 11:35:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE04811E80FD for ; Thu, 9 Jun 2011 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.429 X-Spam-Level: X-Spam-Status: No, score=-10.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lxz2IKHC9Ly for ; Thu, 9 Jun 2011 11:34:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E69DC11E80F3 for ; Thu, 9 Jun 2011 11:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4812; q=dns/txt; s=iport; t=1307644498; x=1308854098; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=e1MC81RWEg3CXuA0Z9r913EIjuXFMBrxwT2RxLARQRQ=; b=ggRmym8dLsx2m8yXohJraDQL67RpMk7/4XAPk4O0hgshdyNG/Kg7/8ii 97V2fWNZXa/zHk0gHHTiE8n0/LIlEE2ZBJneOKZKXW8KxKb2bJLcM4d46 WddIQJygaI3O0LqNWcVAFQU2NNBtAfnBMinKOjEtOL/I5p73bgxIZjngC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC4S8U2rRDoH/2dsb2JhbABTpkB3iHGhIoMIDwGafoYjBJEqhE2LBw X-IronPort-AV: E=Sophos;i="4.65,342,1304294400"; d="scan'208";a="711102998" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2011 18:34:58 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p59IYtsv000538; Thu, 9 Jun 2011 18:34:56 GMT Message-ID: <4DF1124B.4080304@cisco.com> Date: Thu, 09 Jun 2011 20:34:51 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gaurav Thareja References: <5DD781A4BE13384A900438DF0608972C063BE39E@emailemea4.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, Vinod Joseph , idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:35:02 -0000 Hello Gaurav, I agree with almost entire email. "Almost" as I am not clear just on your last sentence and would really like if you could elaborate on it further .. > RTC based > approach in our draft is just optimizing via offering the provider to > not only receive the best two three or more paths to select from but > also offering the flexibilty to prefer the exit ASBR it wish to exit > including the closest one. Practical questions: - How many paths you will want to receive from RR which will be prioritized by RTC ? Assume you have 10 ASBRs peering to your upstreams. - I assume you are still going to request RR to send you the overall best to make sure when all of your preferred paths are going away such PE can still reach the given networks - pls confirm or deny. - If you receive more then one path from RR how are you going to influence best path selection on the PE to make sure that: - the one containing RT X wins the best path selection as the most preferred - the one containing RT Y will be a backup of X. - the one containing community RR will be the one last resort. I am not saying this is easy or difficult .. I am just interested to learn your preference there on how you are going to achieve this on each PE. Best regards, R. > Hi Rob, > > I see it this way. Initially when RR concept was introduced then > even the access devices (PEs) were not of a scale to handle a big > rib-in data base plus also every device in network had to ip switch > the packet across the network and best path to the exit gateway was > not possible in true sense always (from PE prospective). This is > because core routers forwarding decision was independent of access > PEs. However once MPLS is there on the network the switching is based > on the next hop PE selects. There is no significance left anymore for > RR to select the best path first and then forward it further. It > should simply reflect what all routes it receives. And we are talking > about RR not just deciding best path for itself but also for PEs > too. The add path approach is simply serving the concept of true > route reflection. There has been a debate on the increase of rib-in > at PE due to multiple copies of prefixes from different ASBR. RTC > based approach in our draft is just optimizing via offering the > provider to not only receive the best two three or more paths to > select from but also offering the flexibilty to prefer the exit ASBR > it wish to exit including the closest one. > > Regards, G > > On 6/9/11, Vinod Joseph wrote: >> This is proposed specifically to address the need of an operator to >> indicate a list of preferred NHs and in addition to have the option >> of an RR selected path as well. >> >> Regards >> >> Vinod Joseph Sent from my Blackberry Professional Services - >> Service Provider Europe, UK& Ireland Juniper Networks, Inc. +44 >> 7500 835 876 E: vjoseph@juniper.net >> >> >> >> >> ----- Original Message ----- From: Robert Raszuk >> To: >> bruno.decraene@orange-ftgroup.com >> >> Cc: Vinod Joseph; idr@ietf.org >> Sent: Thu Jun 09 09:38:53 2011 Subject: Re: [Idr] >> draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs >> policy based routing) >> >> Hello, >> >> While we are at the RTC topic ... >> >> I see even bigger issue with them defining "special RT" applied at >> RRs to mean send me overall best if my requested RTs are not >> available. >> >> That was used as the explanation on how their proposal will address >> the issue when non of preferred paths are available yet other non >> preferred paths could be used. >> >> That is more like conditional advertisement feature and I don't >> think we have ever intended to combine it with RTC. >> >> Thx, R. >> >> -- On a more detailed / technical level, could you also please >> clarify if your document propose to _use_ RFC 4684 (RTC) or >> _modify/extend_ it? § 5.3 says "It is to be noted that the "Default >> RT" indicates that all prefixes/ paths even without a corresponding >> RT will be considered as candidates for announcements." According >> to my own reading of RFC 4684, the default RTC route matches all RT >> communities. It would not allow requesting routes which have not RT >> community attached to them. Agreed RFC 4684 is not that specific >> on this as it says "receive all VPN route " but IMO this is because >> it assumes that all VPN routes have at least one RT attached on >> it. >> >> >> Thanks, Regards, Bruno >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> > > From jie.dong@huawei.com Fri Jun 10 00:38:04 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABC411E8081 for ; Fri, 10 Jun 2011 00:38:04 -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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9EZJ9r2ykfQ for ; Fri, 10 Jun 2011 00:38:03 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 262E311E80A9 for ; Fri, 10 Jun 2011 00:38:03 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMK008IKD5W9L@szxga05-in.huawei.com> for idr@ietf.org; Fri, 10 Jun 2011 15:37:08 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMK0019CD5KQX@szxga05-in.huawei.com> for idr@ietf.org; Fri, 10 Jun 2011 15:37:08 +0800 (CST) Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 10 Jun 2011 15:36:56 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.8.243]) by szxeml406-hub.china.huawei.com ([169.254.32.110]) with mapi id 14.01.0270.001; Fri, 10 Jun 2011 15:36:55 +0800 Date: Fri, 10 Jun 2011 07:36:54 +0000 From: Jie Dong In-reply-to: <5DD781A4BE13384A900438DF0608972C063BE39E@emailemea4.jnpr.net> X-Originating-IP: [10.110.98.32] To: Vinod Joseph , "raszuk@cisco.com" , "bruno.decraene@orange-ftgroup.com" Message-id: <76CD132C3ADEF848BD84D028D243C927B49531@szxeml508-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) Thread-index: AcwmgKJ0zAAjC4+jTJ68Hvu+Zp/4dwAANrA2AC3oAzA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5DD781A4BE13384A900438DF0608972C063BE39E@emailemea4.jnpr.net> Cc: "gaurav.thareja@gmail.com" , "idr@ietf.org" , "Chintan.Shah@colt.net" Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 07:38:04 -0000 Hi all, If the requirement is to indicate a list of preferred NHs to RR, maybe ther= e can be one straightforward solution: just tell RR an ordered list of pref= erred NHs.=20 This may be achieved by extending the NH Cost SAFI or defining one new SAFI= . If RR knows any valid path with preferred NHs, it would advertise such ro= ute to the PE, otherwise RR would advertise the IGP optimal path from eithe= r the PE's or the RR's perspective. When add-path is used, RR may advertise= both paths with preferred NHs and IGP optimal paths to the PE. The potential benefit is overhead of managing and configuring RTs on ASBRs = and PEs for IPv4/IPv6 unicast could be removed. Besides, the IGP optimal pa= th could be sent to PE when there is no path with preferred NHs or when add= -path is used, i.e. solve the problem without configuring "unique RT" for e= ach RR. Of course, if this policy based routing is a real requirement from operator= s, we could have more discussions on the solution space. Regards, Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Vin= od > Joseph > Sent: Thursday, June 09, 2011 4:45 PM > To: raszuk@cisco.com; bruno.decraene@orange-ftgroup.com > Cc: gaurav.thareja@gmail.com; idr@ietf.org; Chintan.Shah@colt.net > Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (sho= rtest > IGP vs policy based routing) >=20 > This is proposed specifically to address the need of an operator to indic= ate a > list of preferred NHs and in addition to have the option of an RR selecte= d > path as well. >=20 > Regards >=20 > Vinod Joseph > Sent from my Blackberry > Professional Services - Service Provider Europe, UK & Ireland > Juniper Networks, Inc. > +44 7500 835 876 > E: vjoseph@juniper.net >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: Robert Raszuk > To: bruno.decraene@orange-ftgroup.com > > Cc: Vinod Joseph; idr@ietf.org > Sent: Thu Jun 09 09:38:53 2011 > Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection > (shortest IGP vs policy based routing) >=20 > Hello, >=20 > While we are at the RTC topic ... >=20 > I see even bigger issue with them defining "special RT" applied at RRs > to mean send me overall best if my requested RTs are not available. >=20 > That was used as the explanation on how their proposal will address the > issue when non of preferred paths are available yet other non preferred > paths could be used. >=20 > That is more like conditional advertisement feature and I don't think we > have ever intended to combine it with RTC. >=20 > Thx, > R. >=20 > -- > On a more detailed / technical level, could you also please clarify if > your document propose to _use_ RFC 4684 (RTC) or _modify/extend_ it? > =A7 5.3 says "It is to be noted that the "Default RT" indicates that all > prefixes/ paths even without a corresponding RT will be considered as > candidates for announcements." > According to my own reading of RFC 4684, the default RTC route matches > all RT communities. It would not allow requesting routes which have not > RT community attached to them. Agreed RFC 4684 is not that specific on > this as it says "receive all VPN route " but IMO this is because it > assumes that all VPN routes have at least one RT attached on it. >=20 >=20 > Thanks, > Regards, > Bruno > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Fri Jun 10 01:51:27 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AB911E8082 for ; Fri, 10 Jun 2011 01:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkZ9O1dU-Zb3 for ; Fri, 10 Jun 2011 01:51:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id D451B11E807D for ; Fri, 10 Jun 2011 01:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4323; q=dns/txt; s=iport; t=1307695886; x=1308905486; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VPWvvQzlVxB7cv0JNZ1r82fdW2BSlDULHsTZvAX8A6s=; b=GW6H2K1sBMv8s/S6l/dHhzLWQM/5RkH67gUNUmOQxitNXelyUEeB5ylA wEVrr91pfxn81Lv6WFLvnI68s6rsqTh/QERtSCZ8sHYmtpn18EuKJ56jM K4m1EVzbYWJukLjlRZImBDm5cGnbqiC4nyE2pTumMyRiU1dhhQ54ASWRj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBAKLZ8U2rRDoJ/2dsb2JhbABTl1GOdHeIcqA3gw4PAZsHhiMEkSuEToQ/hkw X-IronPort-AV: E=Sophos;i="4.65,345,1304294400"; d="scan'208";a="463190278" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2011 08:51:25 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5A8pMlf002609; Fri, 10 Jun 2011 08:51:23 GMT Message-ID: <4DF1DB20.3040703@cisco.com> Date: Fri, 10 Jun 2011 10:51:44 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jie Dong References: <5DD781A4BE13384A900438DF0608972C063BE39E@emailemea4.jnpr.net> <76CD132C3ADEF848BD84D028D243C927B49531@szxeml508-mbs.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927B49531@szxeml508-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "gaurav.thareja@gmail.com" , "bruno.decraene@orange-ftgroup.com" , "Chintan.Shah@colt.net" , Vinod Joseph , "idr@ietf.org" Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 08:51:27 -0000 Hello Jie, Many thx for your comment. This is exactly what NH-SAFI is already capable of doing and this is what we have explained to Vinod at all number of times in this thread already. IDR WG doc if combined with NH-SAFI draft does both IGP SPF based path selection on a per PE or per POP basis as well as operator's static preference on the choice of paths for set of particular PEs. As you also are correctly observing such policy could be configured on RRs directly for each client without any need for extra NH-SAFI signaling. Many thx, R. > Hi all, > > If the requirement is to indicate a list of preferred NHs to RR, > maybe there can be one straightforward solution: just tell RR an > ordered list of preferred NHs. > > This may be achieved by extending the NH Cost SAFI or defining one > new SAFI. If RR knows any valid path with preferred NHs, it would > advertise such route to the PE, otherwise RR would advertise the IGP > optimal path from either the PE's or the RR's perspective. When > add-path is used, RR may advertise both paths with preferred NHs and > IGP optimal paths to the PE. > > The potential benefit is overhead of managing and configuring RTs on > ASBRs and PEs for IPv4/IPv6 unicast could be removed. Besides, the > IGP optimal path could be sent to PE when there is no path with > preferred NHs or when add-path is used, i.e. solve the problem > without configuring "unique RT" for each RR. > > Of course, if this policy based routing is a real requirement from > operators, we could have more discussions on the solution space. > > Regards, Jie > >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of Vinod Joseph Sent: >> Thursday, June 09, 2011 4:45 PM To: raszuk@cisco.com; >> bruno.decraene@orange-ftgroup.com Cc: gaurav.thareja@gmail.com; >> idr@ietf.org; Chintan.Shah@colt.net Subject: Re: [Idr] >> draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs >> policy based routing) >> >> This is proposed specifically to address the need of an operator to >> indicate a list of preferred NHs and in addition to have the option >> of an RR selected path as well. >> >> Regards >> >> Vinod Joseph Sent from my Blackberry Professional Services - >> Service Provider Europe, UK& Ireland Juniper Networks, Inc. +44 >> 7500 835 876 E: vjoseph@juniper.net >> >> >> >> >> ----- Original Message ----- From: Robert Raszuk >> To: bruno.decraene@orange-ftgroup.com >> Cc: Vinod Joseph; >> idr@ietf.org Sent: Thu Jun 09 09:38:53 2011 Subject: >> Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection >> (shortest IGP vs policy based routing) >> >> Hello, >> >> While we are at the RTC topic ... >> >> I see even bigger issue with them defining "special RT" applied at >> RRs to mean send me overall best if my requested RTs are not >> available. >> >> That was used as the explanation on how their proposal will address >> the issue when non of preferred paths are available yet other non >> preferred paths could be used. >> >> That is more like conditional advertisement feature and I don't >> think we have ever intended to combine it with RTC. >> >> Thx, R. >> >> -- On a more detailed / technical level, could you also please >> clarify if your document propose to _use_ RFC 4684 (RTC) or >> _modify/extend_ it? § 5.3 says "It is to be noted that the "Default >> RT" indicates that all prefixes/ paths even without a corresponding >> RT will be considered as candidates for announcements." According >> to my own reading of RFC 4684, the default RTC route matches all RT >> communities. It would not allow requesting routes which have not RT >> community attached to them. Agreed RFC 4684 is not that specific >> on this as it says "receive all VPN route " but IMO this is because >> it assumes that all VPN routes have at least one RT attached on >> it. >> >> >> Thanks, Regards, Bruno >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > From reshmi_prem@yahoo.com Fri Jun 10 04:15:10 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B38211E809F for ; Fri, 10 Jun 2011 04:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_EXTRA_CLOSE=2.809, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laYZacCw0GdF for ; Fri, 10 Jun 2011 04:15:09 -0700 (PDT) Received: from nm6.bullet.mail.ac4.yahoo.com (nm6.bullet.mail.ac4.yahoo.com [98.139.52.203]) by ietfa.amsl.com (Postfix) with SMTP id 345E911E807E for ; Fri, 10 Jun 2011 04:15:09 -0700 (PDT) Received: from [98.139.52.195] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 11:15:06 -0000 Received: from [98.139.52.167] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 11:15:06 -0000 Received: from [127.0.0.1] by omp1050.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 11:15:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 160648.61625.bm@omp1050.mail.ac4.yahoo.com Received: (qmail 86503 invoked by uid 60001); 10 Jun 2011 11:15:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307704505; bh=yMOi+AVXskyHNkqYL3ywErX7oUOz3eZr4BFCb6KwrVg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=ffpzvDF/FP6bjFOW8lSwzY1DFznFT/ieNYz1ckSAXFThJx+2B5rhIg12WcMLLoB6HZ86P6r8PNSNTjiK8ZkZ9aQObv254ljlxgD8ltM8b+2fvA9DpN917rr0QiRRvoj/DGfj2Aeqb55Q3KqmRPdP6VhE5KPPosF9nOqHL78hG9o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=hnRiF6gXMDtbprvIlv38235Is3oNij6gs8ByFvxj2qnAQJ3itmADOqjxeWncirJCrUHLSM+XES0TmRcpm2DrLyrb2Nqpm4g20zoHGdtrGP5CRSFT2F562p4owKzWDKZ/R3nn75pnBgvll++kYLaoEOWHFmZkAmyQ/ejzsGSPFv0=; Message-ID: <515583.80521.qm@web37908.mail.mud.yahoo.com> X-YMail-OSG: JjhuywYVM1mUnrRZLST5cz_2LbqY1HOBT9gF3xo3k2dqjWY dhwKMsdeU8e84zelTdJMDEjqxjDaiikn.hSNCIq9dkjh49QBHN68ymp4f72M rF7bV3yjjVqm.RrZJJT6Gj_1yZyd7Aksptvoxj35UNTpRNpw8Mdx9pe3ppc. 5RDjwDAKXXSyUdFFLQCmXswMAiejYqmKMLggXnyLQ9lKozAL8aRRpVbXf1VI 3y1nNK7986WnZjH6FhRf2nvfkfTNUqKk9oxWNfo7E2ZnRoqbRWFBg87vzrtQ zrFU0.7RwQtE1UjFLsdRiqBmyTyU5Va7D_zyxGeWcrLMeaAzPlTtZVn3TVxl y52EnGFAxbmdb1xDHTDGoY84VkvxaqCZ0mIONMwoPCozgKzST0lxo1jE9JT8 IZRr154wDudrJ Received: from [217.43.52.160] by web37908.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 04:15:05 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 04:15:05 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1084256261-1307704505=:80521" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:15:10 -0000 --0-1084256261-1307704505=:80521 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Robert and All, =A0 I have been following this discussion and I would like add my opinions here =A0 We have been having similar requirements to steer traffic through selective= exit points in the network which are driven by customer requirements, exam= ple having premium customers use a set of ASBRS vs. a different set of othe= r customers using another set of ASBRs within a given region/POP or whateve= r you may like to call it. In effect, IGP metric may not always be the the = choice in=A0our case.=20 =A0 As an opertor I am interested in the best solution and the more options we = see, the better for us to choose what is appropriate for us. However I do n= ot see this being reflected in any of the discussions here unfortunately.= =20 =A0 Back to the point, using a NH SAFI if I need three ASBR paths on a PE (let = me call this Premium PE), I do have to modify the admin costs on each of th= ese sets of PEs to each of the ASBR manually to a metric=A0that will influe= nce the RR to announce the best path to the=A0PE. You state multiple paths = can be announced as well - let us say I need 3. Is this using ADD-PATH? If = so how do you compute the best path on ADD-PATH? =A0 On the draft using RT and RTC, I do clearly see the means of achieving a se= t of preferred paths being advertised and received on the PE. The RR in thi= s case strictly announces paths that match a given RT list which can also b= e controlled in regard to how many paths a PE is interested in. I would ima= gine that in the event of a path being withdrawn, the RR would send an alte= rnate path with the same RT if it is available, as it what ADD-PATH is expe= cted to do=A0in any case which is announce additional paths if announced pa= ths are withdrawn - I specifically refer to the case where pure ADD-PATH im= plementations constrain the number of paths to a specific number of paths (= min and max no. of paths). =A0 RT configurations are not a overhead for us, and I do not expect everyone t= o feel the same. If we were to implement this solution for us, I would just= configure ASBRs with Route Targets specific to our needs, and have the PEs= choose between them. Its simple for me since even IP addressing needs plan= ning, VPNv4 RT allocations needed planning when we implemented RT. I am not= drawing parallels, but I am more focussed on the ease of adding new RTs wh= enever a new requirement comes up. On the topic of ensuring the best path o= n the PE which someone raised, I would use a local policy to influence that= . Probably use "weights" or some equivalent or expect the authors of this d= raft to have a mechanism to probably specify a method of assigning a weight= to each RT, rather than having the RR do something here. =A0 I am personally not comfortable and a strong advocate against running an SP= F instance - in whatever shape on my RR. I do want any IGP related issue, b= e it a software bug or any other problem in respect to the RR having the ne= ed to have an IGP view of sorts - to impact the BGP machine. Whatever the p= romises are I would want to see this perform in my lab under different cont= raints using production code before this can be looked at. =A0 Summary - Nice to have two choices, a. SPF on RR for closest IGP announceme= nt b. Use RTs and RTC to have preference or operator based path announcemen= t, with the favour tilting towards the RT approach as both the drafts in it= s present form stand today. =A0Prem --0-1084256261-1307704505=:80521 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Robert and All,

 

I have been following this discussion and I would like add = my opinions here

 

We have been having similar requirements to steer traffic t= hrough selective exit points in the network which are driven by customer re= quirements, example having premium customers use a set of ASBRS vs. a diffe= rent set of other customers using another set of ASBRs within a given regio= n/POP or whatever you may like to call it. In effect, IGP metric may not al= ways be the the choice in our case.

 

As an opertor I am interested in the best solution and the = more options we see, the better for us to choose what is appropriate for us= . However I do not see this being reflected in any of the discussions here = unfortunately.

 

Back to the point, using a NH SAFI if I need three ASBR pat= hs on a PE (let me call this Premium PE), I do have to modify the admin cos= ts on each of these sets of PEs to each of the ASBR manually to a metric&nb= sp;that will influence the RR to announce the best path to the PE. You= state multiple paths can be announced as well - let us say I need 3. Is th= is using ADD-PATH? If so how do you compute the best path on ADD-PATH?

 

On the draft using RT and RTC, I do clearly see the means o= f achieving a set of preferred paths being advertised and received on the P= E. The RR in this case strictly announces paths that match a given RT list = which can also be controlled in regard to how many paths a PE is interested= in. I would imagine that in the event of a path being withdrawn, the RR wo= uld send an alternate path with the same RT if it is available, as it what = ADD-PATH is expected to do in any case which is announce additional pa= ths if announced paths are withdrawn - I specifically refer to the case whe= re pure ADD-PATH implementations constrain the number of paths to a specifi= c number of paths (min and max no. of paths).

 

RT configurations are not a overhead for us, and I do not e= xpect everyone to feel the same. If we were to implement this solution for = us, I would just configure ASBRs with Route Targets specific to our needs, = and have the PEs choose between them. Its simple for me since even IP addre= ssing needs planning, VPNv4 RT allocations needed planning when we implemen= ted RT. I am not drawing parallels, but I am more focussed on the ease of a= dding new RTs whenever a new requirement comes up. On the topic of ensuring= the best path on the PE which someone raised, I would use a local policy t= o influence that. Probably use "weights" or some equivalent or expect the a= uthors of this draft to have a mechanism to probably specify a method of as= signing a weight to each RT, rather than having the RR do something here.

 

I am personally not comfortable and a strong advocate again= st running an SPF instance - in whatever shape on my RR. I do want any IGP = related issue, be it a software bug or any other problem in respect to the = RR having the need to have an IGP view of sorts - to impact the BGP machine= . Whatever the promises are I would want to see this perform in my lab unde= r different contraints using production code before this can be looked at.<= /FONT>

 

Summary - Nice to have two choices, a. SPF on RR for closes= t IGP announcement b. Use RTs and RTC to have preference or operator based = path announcement, with the favour tilting towards the RT approach as both = the drafts in its present form stand today.

 Prem

--0-1084256261-1307704505=:80521-- From raszuk@cisco.com Fri Jun 10 05:23:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C958711E807C for ; Fri, 10 Jun 2011 05:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwqTIlI0G0ra for ; Fri, 10 Jun 2011 05:23:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id CF0D811E80A2 for ; Fri, 10 Jun 2011 05:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=6776; q=dns/txt; s=iport; t=1307708624; x=1308918224; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pKkECojctx0pR5HgocR90IAS17rsVEtGM95/J+nyofo=; b=Q7WbmOmEuKbBwWkXjDcKQD2k1Z/dTJfKTqsNHL9FYlXQdXNyeneaYlna 8H9rYf03fQHPh79d27njZY45roifriAmhz8fE+B1L4Sv9fiss1H4NPgZ0 jXNXhHKOM5yF1awjlc37kPch/D9GY5Y9H5Hdtfx8FcMA3J6f2TYfE9hhO k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJAL8k2rRDoI/2dsb2JhbABTpkV3iHKfZYMODwGacYYjBJErhE6LCw X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="374170165" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2011 12:23:44 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5ACNf02018217; Fri, 10 Jun 2011 12:23:42 GMT Message-ID: <4DF20CC8.5050208@cisco.com> Date: Fri, 10 Jun 2011 14:23:36 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <515583.80521.qm@web37908.mail.mud.yahoo.com> In-Reply-To: <515583.80521.qm@web37908.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:23:45 -0000 Hi Reshmi and All, Many thx for your input. I think I have a very good news for you and for other operators which require policy based preferred exit management. All of your stated requirements can be acoomplished _today_ in your current network without any need to: - wait for new ietf consensus, - extend and modify RTC behaviour on RRs - add or delete any RT in the network - introduce notion of "special RT" on the RR - change the semantics of "default RT" as noticed by Bruno - correlate RT values between PEs and ASBRs - use add-paths or wait for your PE/RR/ASBR to support it - add any single line of new code to existing network operating systems The solution I am suggesting is very simple and straight forward. Let's call it: "Hybrid IBGP Sessions" Description: ------------ To address your requirements all what is needed is to add 1 or 2 additional IBGP session from PE to set of exit ASBRs of choice. On PE's inbound side you configure on a per session basis weight or local pref accordingly to your preference and you are done. You keep your existing session to RR just to make sure you always learn some best path when your preferred best paths are gone. Your second session to your back-up RR is not optional. As a matter of fact you can remove it or you can transition it from such backup RR to receive diverse-path as described in draft-ietf-grow-diverse-bgp-path-dist. That will even further enhance your network robustness and fault tolerance - but this is totally optional. Discussion: ----------- Since PEs today support 1000s of BGP sessions adding one or two there should not be a problem to anyone. Now one may argue that you would need to do a lot of configuration on the ASBRs to add/delete IBGP sessions there. Nothing more mistaken. \ Note that decent BGP implementations already for a long time support single sided BGP session provisioning. So all ASBRs can be configured today to automatically accept IBGP session requests from pre-configured range of peer's session addresses. If that security measure is not sufficient there is also an option do add MD5 signature match. Also note that this does not put any additional burden on ASBRs as all of those PEs will be in the same peer group there. And as we all know replication is a very CPU cheap process. RRs remain as is. No single change needed. They continue to have peers in the single peer group and no single additional SPF is executed there. In other words RRs are tools to help operator instead of pushing more burden on them. While they can help in network operation and I am still very much convinced that running few more spf there is in the noise of their powers. They can also be completely bypassed when there is operational or commercial need to prefer set of exit points on a per PE basis just like demonstrated above in "Hybrid IBGP Sessions" case. I hope your customers will be happy to exit via preferred ASBRs very soon. If you or anyone on the IDR WG list think that more formal description of this basic behaviour is required I will be more then happy to turn this into 1-2 page informational draft as well. Best regards, R. > Robert and All, > > I have been following this discussion and I would like add my opinions here > > We have been having similar requirements to steer traffic through > selective exit points in the network which are driven by customer > requirements, example having premium customers use a set of ASBRS vs. a > different set of other customers using another set of ASBRs within a > given region/POP or whatever you may like to call it. In effect, IGP > metric may not always be the the choice in our case. > > As an opertor I am interested in the best solution and the more options > we see, the better for us to choose what is appropriate for us. However > I do not see this being reflected in any of the discussions here > unfortunately. > > Back to the point, using a NH SAFI if I need three ASBR paths on a PE > (let me call this Premium PE), I do have to modify the admin costs on > each of these sets of PEs to each of the ASBR manually to a metric that > will influence the RR to announce the best path to the PE. You state > multiple paths can be announced as well - let us say I need 3. Is this > using ADD-PATH? If so how do you compute the best path on ADD-PATH? > > On the draft using RT and RTC, I do clearly see the means of achieving a > set of preferred paths being advertised and received on the PE. The RR > in this case strictly announces paths that match a given RT list which > can also be controlled in regard to how many paths a PE is interested > in. I would imagine that in the event of a path being withdrawn, the RR > would send an alternate path with the same RT if it is available, as it > what ADD-PATH is expected to do in any case which is announce additional > paths if announced paths are withdrawn - I specifically refer to the > case where pure ADD-PATH implementations constrain the number of paths > to a specific number of paths (min and max no. of paths). > > RT configurations are not a overhead for us, and I do not expect > everyone to feel the same. If we were to implement this solution for us, > I would just configure ASBRs with Route Targets specific to our needs, > and have the PEs choose between them. Its simple for me since even IP > addressing needs planning, VPNv4 RT allocations needed planning when we > implemented RT. I am not drawing parallels, but I am more focussed on > the ease of adding new RTs whenever a new requirement comes up. On the > topic of ensuring the best path on the PE which someone raised, I would > use a local policy to influence that. Probably use "weights" or some > equivalent or expect the authors of this draft to have a mechanism to > probably specify a method of assigning a weight to each RT, rather than > having the RR do something here. > > I am personally not comfortable and a strong advocate against running an > SPF instance - in whatever shape on my RR. I do want any IGP related > issue, be it a software bug or any other problem in respect to the RR > having the need to have an IGP view of sorts - to impact the BGP > machine. Whatever the promises are I would want to see this perform in > my lab under different contraints using production code before this can > be looked at. > > Summary - Nice to have two choices, a. SPF on RR for closest IGP > announcement b. Use RTs and RTC to have preference or operator based > path announcement, with the favour tilting towards the RT approach as > both the drafts in its present form stand today. > > Prem From raszuk@cisco.com Fri Jun 10 05:27:26 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EC611E80C2 for ; Fri, 10 Jun 2011 05:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.451 X-Spam-Level: X-Spam-Status: No, score=-10.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ipnYDFD1lbO for ; Fri, 10 Jun 2011 05:27:25 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C925911E80A5 for ; Fri, 10 Jun 2011 05:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=175; q=dns/txt; s=iport; t=1307708845; x=1308918445; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lXtK3VLh1om5lEhrFuMtuxqDdjifUfTYjWZh+XvbrWc=; b=cY+Q2nsk2yByFQBMjSL6RhoQkzToClPsrYlRJZAzHzGKQ3c8mukyEcIQ ogUQARZLUkFLCLCNbeVufkHhVQh5K1wUX+hjYWmxOQiLidHfgLOItVBiX zZJ47a2YM9/28XSuGMeyF0lcKUri+7K33YsXoI9NGDGoXiPXcAXr08b85 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADgN8k2rRDoG/2dsb2JhbABSpkV3qEGDDg8BmnGGIwSRK4ROiws X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="334311763" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2011 12:27:14 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ACRCH0007065; Fri, 10 Jun 2011 12:27:12 GMT Message-ID: <4DF20D9B.1000300@cisco.com> Date: Fri, 10 Jun 2011 14:27:07 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <515583.80521.qm@web37908.mail.mud.yahoo.com> <4DF20CC8.5050208@cisco.com> In-Reply-To: <4DF20CC8.5050208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:27:26 -0000 Small typo .. Is: Your second session to your back-up RR is not optional. Should be: Your second session to your back-up RR is _now_ optional. Apologies, RR. From reshmi_prem@yahoo.com Fri Jun 10 05:28:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3EE11E80CC for ; Fri, 10 Jun 2011 05:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLXZKpkElf6E for ; Fri, 10 Jun 2011 05:28:54 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with SMTP id C60E611E807C for ; Fri, 10 Jun 2011 05:28:53 -0700 (PDT) Received: from [98.139.212.153] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 12:28:49 -0000 Received: from [98.139.212.216] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 12:28:49 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 12:28:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 642140.27825.bm@omp1025.mail.bf1.yahoo.com Received: (qmail 67266 invoked by uid 60001); 10 Jun 2011 12:28:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307708929; bh=2CqWc5EwO2CyZnwipvve5L0fvOdH7SbbdHnSpF6rv7Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WWNx2PqQPuF2iQ4C2SOcddgAmjPyjXfj+HlcEaP++A/uqaKQF4CvLY/UM0uzTqAAvTLBxUBjhDLDiiEtAyIhmXbRGQjqofRuFcYPSzAxzKEtPOD3/B4WR9yLnzVXnJ3F841BLDDnywj1SVpVy5fyZ4wW07cP2ji1XEVjrat2RcM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qTWg7Hr6pGSsGX7dYtLJ9wbEwpD2KVz8UwIUZt05WkDGmTbraEGMn198YYoaZVZoUZptoiLbpJ+BTl9LFFx2YxHX+3HBRGpWXVXePsQe3dHp/Ahi5uKeMMXyhCGWMHJ0px5TuKOYm62gAH8xf1lUb0Bez7v8NgY1jz1Q1ijuJ6g=; Message-ID: <178628.47670.qm@web37905.mail.mud.yahoo.com> X-YMail-OSG: TGrnL1YVM1ljyEMODVCGr.6VistwiAwgaqzHFJhmmqjN5Gw VvXMM7mzdwR1p5Vc0EnFc7Z6kQZiIbBbIzOcXvl55avDyurBW6n1RcWdd3R5 W.xYVvzxg.jUYrInxuTH0Zr91IeySbgun49GUdovyWFrYX_R3JFKmFfXEhhV Poh1lFYKx4q.jOTu7g4j25p1PB60c3HXUT1LCx5T4s4YturwDmAhOBHZVqBK al.AFeW1niRopzohaaI00mpw6J4_068E3QF4mp7a.PIh3VkHJrZq_JBNUF5k XkwdoEFIZ7XSmSpq.ZuLnprcQf4vxB5qg6ATfv7oNSylX6jhVEN1p16_Q3aO XVUrwB2BGBFUH_lkkfVEwb_F8mOQG4Ihz59bSb5KHpRG3QjO1zrIc6UsN2_. 4j6TKe1PUnOCiyw-- Received: from [66.129.224.36] by web37905.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 05:28:49 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 05:28:49 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF20CC8.5050208@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-588162001-1307708929=:47670" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:28:55 -0000 --0-588162001-1307708929=:47670 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sorry about that - The idea of iBGP sessions between PE and ASBR etc does n= ot fit our needs, but thanks for the very innovative advise. I expected a m= ore mature response to the feedback I had offered, but it seems you are tot= ally not in a mood to look at my views and answer my questions but just see= m to say "what i offer is the best - take it or leave it".=A0and you want t= o make a statement. I feel there is no point in having a discussion with a = person with ideas like you. =A0 Prem --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 7:23 AM Hi Reshmi and All, Many thx for your input. I think I have a very good news for you and for ot= her operators which require policy based preferred exit management. All of your stated requirements can be acoomplished _today_ in your current= network without any need to: - wait for new ietf consensus, - extend and modify RTC behaviour on RRs - add or delete any RT in the network - introduce notion of "special RT" on the RR - change the semantics of "default RT" as noticed by Bruno - correlate RT values between PEs and ASBRs - use add-paths or wait for your PE/RR/ASBR to support it - add any single line of new code to existing network operating systems The solution I am suggesting is very simple and straight forward. Let's cal= l it: "Hybrid IBGP Sessions" Description: ------------ To address your requirements all what is needed is to add 1 or 2 additional= IBGP session from PE to set of exit ASBRs of choice. On PE's inbound side = you configure on a per session basis weight or local pref accordingly to yo= ur preference and you are done. You keep your existing session to RR just to make sure you always learn som= e best path when your preferred best paths are gone. Your second session to your back-up RR is not optional. As a matter of fact= you can remove it or you can transition it from such backup RR to receive = diverse-path as described in draft-ietf-grow-diverse-bgp-path-dist. That wi= ll even further enhance your network robustness and fault tolerance - but t= his is totally optional. Discussion: ----------- Since PEs today support 1000s of BGP sessions adding one or two there shoul= d not be a problem to anyone. Now one may argue that you would need to do a lot of configuration on the A= SBRs to add/delete IBGP sessions there. Nothing more mistaken. \ Note that decent BGP implementations already for a long time support single= sided BGP session provisioning. So all ASBRs can be configured today to au= tomatically accept IBGP session requests from pre-configured range of peer'= s session addresses. If that security measure is not sufficient there is al= so an option do add MD5 signature match. Also note that this does not put any additional burden on ASBRs as all of t= hose PEs will be in the same peer group there. And as we all know replicati= on is a very CPU cheap process. RRs remain as is. No single change needed. They continue to have peers in t= he single peer group and no single additional SPF is executed there. In other words RRs are tools to help operator instead of pushing more burde= n on them. While they can help in network operation and I am still very muc= h convinced that running few more spf there is in the noise of their powers= . They can also be completely bypassed when there is operational or commerc= ial need to prefer set of exit points on a per PE basis just like demonstra= ted above in "Hybrid IBGP Sessions" case. I hope your customers will be happy to exit via preferred ASBRs very soon. = If you or anyone on the IDR WG list think that more formal description of t= his basic behaviour is required I will be more then happy to turn this into= 1-2 page informational draft as well. Best regards, R. > Robert and All, >=20 > I have been following this discussion and I would like add my opinions he= re >=20 > We have been having similar requirements to steer traffic through > selective exit points in the network which are driven by customer > requirements, example having premium customers use a set of ASBRS vs. a > different set of other customers using another set of ASBRs within a > given region/POP or whatever you may like to call it. In effect, IGP > metric may not always be the the choice in our case. >=20 > As an opertor I am interested in the best solution and the more options > we see, the better for us to choose what is appropriate for us. However > I do not see this being reflected in any of the discussions here > unfortunately. >=20 > Back to the point, using a NH SAFI if I need three ASBR paths on a PE > (let me call this Premium PE), I do have to modify the admin costs on > each of these sets of PEs to each of the ASBR manually to a metric that > will influence the RR to announce the best path to the PE. You state > multiple paths can be announced as well - let us say I need 3. Is this > using ADD-PATH? If so how do you compute the best path on ADD-PATH? >=20 > On the draft using RT and RTC, I do clearly see the means of achieving a > set of preferred paths being advertised and received on the PE. The RR > in this case strictly announces paths that match a given RT list which > can also be controlled in regard to how many paths a PE is interested > in. I would imagine that in the event of a path being withdrawn, the RR > would send an alternate path with the same RT if it is available, as it > what ADD-PATH is expected to do in any case which is announce additional > paths if announced paths are withdrawn - I specifically refer to the > case where pure ADD-PATH implementations constrain the number of paths > to a specific number of paths (min and max no. of paths). >=20 > RT configurations are not a overhead for us, and I do not expect > everyone to feel the same. If we were to implement this solution for us, > I would just configure ASBRs with Route Targets specific to our needs, > and have the PEs choose between them. Its simple for me since even IP > addressing needs planning, VPNv4 RT allocations needed planning when we > implemented RT. I am not drawing parallels, but I am more focussed on > the ease of adding new RTs whenever a new requirement comes up. On the > topic of ensuring the best path on the PE which someone raised, I would > use a local policy to influence that. Probably use "weights" or some > equivalent or expect the authors of this draft to have a mechanism to > probably specify a method of assigning a weight to each RT, rather than > having the RR do something here. >=20 > I am personally not comfortable and a strong advocate against running an > SPF instance - in whatever shape on my RR. I do want any IGP related > issue, be it a software bug or any other problem in respect to the RR > having the need to have an IGP view of sorts - to impact the BGP > machine. Whatever the promises are I would want to see this perform in > my lab under different contraints using production code before this can > be looked at. >=20 > Summary - Nice to have two choices, a. SPF on RR for closest IGP > announcement b. Use RTs and RTC to have preference or operator based > path announcement, with the favour tilting towards the RT approach as > both the drafts in its present form stand today. >=20 > Prem --0-588162001-1307708929=:47670 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <= /tr>
Sorry about that - The idea of iBGP sess= ions between PE and ASBR etc does not fit our needs, but thanks for the ver= y innovative advise. I expected a more mature response to the feedback I ha= d offered, but it seems you are totally not in a mood to look at my views a= nd answer my questions but just seem to say "what i offer is the best - tak= e it or leave it". and you want to make a statement. I feel there is n= o point in having a discussion with a person with ideas like you.
 
Prem

--- On Fri, 6/10/11, Robert Raszuk <raszuk@cisco.= com> wrote:

From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 7:23 AM

Hi Reshmi and All,

Many thx for your input. I= think I have a very good news for you and for other operators which requir= e policy based preferred exit management.

All of your stated require= ments can be acoomplished _today_ in your current network without any need = to:

- wait for new ietf consensus,
- extend and modify RTC behavi= our on RRs
- add or delete any RT in the network
- introduce notion o= f "special RT" on the RR
- change the semantics of "default RT" as notic= ed by Bruno
- correlate RT values between PEs and ASBRs
- use add-pat= hs or wait for your PE/RR/ASBR to support it
- add any single line of ne= w code to existing network operating systems

The solution I am sugge= sting is very simple and straight forward. Let's call it:

"Hybrid IB= GP Sessions"

Description:
------------

To address your req= uirements all what is needed is to add 1 or 2 additional IBGP session from PE to set of exit ASBRs of choice. On PE's inbound side you configure= on a per session basis weight or local pref accordingly to your preference= and you are done.

You keep your existing session to RR just to make= sure you always learn some best path when your preferred best paths are go= ne.

Your second session to your back-up RR is not optional. As a mat= ter of fact you can remove it or you can transition it from such backup RR = to receive diverse-path as described in draft-ietf-grow-diverse-bgp-path-di= st. That will even further enhance your network robustness and fault tolera= nce - but this is totally optional.

Discussion:
-----------
Since PEs today support 1000s of BGP sessions adding one or two there sho= uld not be a problem to anyone.

Now one may argue that you would nee= d to do a lot of configuration on the ASBRs to add/delete IBGP sessions the= re. Nothing more mistaken. \

Note that decent BGP implementations already for a long time support single sided BGP session p= rovisioning. So all ASBRs can be configured today to automatically accept I= BGP session requests from pre-configured range of peer's session addresses.= If that security measure is not sufficient there is also an option do add = MD5 signature match.

Also note that this does not put any additional= burden on ASBRs as all of those PEs will be in the same peer group there. = And as we all know replication is a very CPU cheap process.

RRs rema= in as is. No single change needed. They continue to have peers in the singl= e peer group and no single additional SPF is executed there.

In othe= r words RRs are tools to help operator instead of pushing more burden on th= em. While they can help in network operation and I am still very much convi= nced that running few more spf there is in the noise of their powers. They = can also be completely bypassed when there is operational or commercial need to prefer set of exit points on a per PE basis just like d= emonstrated above in "Hybrid IBGP Sessions" case.

I hope your custom= ers will be happy to exit via preferred ASBRs very soon. If you or anyone o= n the IDR WG list think that more formal description of this basic behaviou= r is required I will be more then happy to turn this into 1-2 page informat= ional draft as well.

Best regards,
R.






= > Robert and All,
>
> I have been following this discussion= and I would like add my opinions here
>
> We have been having= similar requirements to steer traffic through
> selective exit point= s in the network which are driven by customer
> requirements, example= having premium customers use a set of ASBRS vs. a
> different set of= other customers using another set of ASBRs within a
> given region/P= OP or whatever you may like to call it. In effect, IGP
> metric may not always be the the choice in our case.
>
> As a= n opertor I am interested in the best solution and the more options
>= we see, the better for us to choose what is appropriate for us. However> I do not see this being reflected in any of the discussions here
&= gt; unfortunately.
>
> Back to the point, using a NH SAFI if I= need three ASBR paths on a PE
> (let me call this Premium PE), I do = have to modify the admin costs on
> each of these sets of PEs to each= of the ASBR manually to a metric that
> will influence the RR to ann= ounce the best path to the PE. You state
> multiple paths can be anno= unced as well - let us say I need 3. Is this
> using ADD-PATH? If so = how do you compute the best path on ADD-PATH?
>
> On the draft= using RT and RTC, I do clearly see the means of achieving a
> set of= preferred paths being advertised and received on the PE. The RR
> in this case strictly announces paths that match a given RT lis= t which
> can also be controlled in regard to how many paths a PE is = interested
> in. I would imagine that in the event of a path being wi= thdrawn, the RR
> would send an alternate path with the same RT if it= is available, as it
> what ADD-PATH is expected to do in any case wh= ich is announce additional
> paths if announced paths are withdrawn -= I specifically refer to the
> case where pure ADD-PATH implementatio= ns constrain the number of paths
> to a specific number of paths (min= and max no. of paths).
>
> RT configurations are not a overhe= ad for us, and I do not expect
> everyone to feel the same. If we wer= e to implement this solution for us,
> I would just configure ASBRs w= ith Route Targets specific to our needs,
> and have the PEs choose be= tween them. Its simple for me since even IP
> addressing needs planning, VPNv4 RT allocations needed planning when we
> implemented= RT. I am not drawing parallels, but I am more focussed on
> the ease= of adding new RTs whenever a new requirement comes up. On the
> topi= c of ensuring the best path on the PE which someone raised, I would
>= use a local policy to influence that. Probably use "weights" or some
&g= t; equivalent or expect the authors of this draft to have a mechanism to> probably specify a method of assigning a weight to each RT, rather th= an
> having the RR do something here.
>
> I am personall= y not comfortable and a strong advocate against running an
> SPF inst= ance - in whatever shape on my RR. I do want any IGP related
> issue,= be it a software bug or any other problem in respect to the RR
> hav= ing the need to have an IGP view of sorts - to impact the BGP
> machi= ne. Whatever the promises are I would want to see this perform in
> my lab under different contraints using production code before = this can
> be looked at.
>
> Summary - Nice to have two = choices, a. SPF on RR for closest IGP
> announcement b. Use RTs and R= TC to have preference or operator based
> path announcement, with the= favour tilting towards the RT approach as
> both the drafts in its p= resent form stand today.
>
> Prem
--0-588162001-1307708929=:47670-- From raszuk@cisco.com Fri Jun 10 05:33:14 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCA211E80E8 for ; Fri, 10 Jun 2011 05:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D--5EKbu8+OE for ; Fri, 10 Jun 2011 05:33:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69711E80C4 for ; Fri, 10 Jun 2011 05:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=273; q=dns/txt; s=iport; t=1307709193; x=1308918793; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Znizoz9yjhCo9GMUIIOUh10cTXkTFoayaJeNLZkUw7Q=; b=kFwbrfAv22GruyjnfYH7w78R6QXTjjFOqBO0u+eiqKx6sybHNS+6lrz5 0r49CHorqljkLT15BNg07w6qLEwhwM6TJS8BPMjwL1bpuL2z3XsR76sye bbhlpHdKIWe7/dgCsFKz5TuGoFIyrFDz/BR6Zoh/WePILwYfJft66prGN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACQO8k2rRDoG/2dsb2JhbABSpkV3iHKfVoMODwGacYYjBJErhE6LCw X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="711535725" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 10 Jun 2011 12:33:13 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ACXBLk011554; Fri, 10 Jun 2011 12:33:11 GMT Message-ID: <4DF20F02.9000700@cisco.com> Date: Fri, 10 Jun 2011 14:33:06 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <178628.47670.qm@web37905.mail.mud.yahoo.com> In-Reply-To: <178628.47670.qm@web37905.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:33:14 -0000 > Sorry about that - The idea of iBGP sessions between PE and ASBR etc > does not fit our needs, but thanks for the very innovative advise. Can you please elaborate why the idea of adding iBGP sessions between PE and ASBR etc does not fit your needs ? Thx, R. From reshmi_prem@yahoo.com Fri Jun 10 05:36:11 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECED711E80C4 for ; Fri, 10 Jun 2011 05:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsuKNQ-H5g6E for ; Fri, 10 Jun 2011 05:36:11 -0700 (PDT) Received: from nm2-vm0.bullet.mail.bf1.yahoo.com (nm2-vm0.bullet.mail.bf1.yahoo.com [98.139.213.127]) by ietfa.amsl.com (Postfix) with SMTP id 1F1C111E807C for ; Fri, 10 Jun 2011 05:36:11 -0700 (PDT) Received: from [98.139.212.151] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 12:36:10 -0000 Received: from [98.139.212.218] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 12:36:10 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 12:36:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 572311.2453.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 40328 invoked by uid 60001); 10 Jun 2011 12:36:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307709369; bh=DtjsSRl7Sm9lo6a8D7yQSJxKMB8QsAq8MO/DvoeOGTY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OSFSumszpmT6z3rvEYyjlOp1S2v5C1BEiVHj10gleUZtZZzbcc0sJICoWG73YDH1GOC/ZDYqPDAyOQbpZ59nbstnnQDO3wD3gt7NlRhNi0OhF23dO8S+HAvIMW1d6rYvKzW/GwIxe6uqMzafzLr/9uiqEpGSf34EzsdvwDvOyZM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=B+bvPZCqLt/ZCYeUlpq+oYRE4K0+nXqT15RL9wdopzQdI6vRN1tv1xHxkmKwsLY18ajgs6zAljysbp0cMb1b5N5P1R/30/8iJ585sYFQUHutj5ABBZI81ZfDAkOJlYAU5eSu1X8zCmrbkAgeYXj3wpHSxUgwNgTe5LeaF93HF9Q=; Message-ID: <870091.40312.qm@web37902.mail.mud.yahoo.com> X-YMail-OSG: I0BYBokVM1kEi8Lj4YonkH4QlNVaBw91_oiNjuXVlDee6xC hv0Jt2EyPeks_hBOWLUtwlzZr05o69mitZY2Tg.28E7DFMTXEgsj767Z5Qa5 qQQ3cplVu2XyROnNXg7xRSNiMhVK9jt4jg4AAxUDBoXselTks6kqDJVkX_FN 1HoYiXBqqDUQjgB4WItBVE8wJ3Zr2ZXo4Bi0e7dUQSu2JN5mlm1EAvEJOOmO Z7AFX5ZRtMcATnZltp_Xm7JuSj2Sxzp3Msb69kcj41eWwmygfHYvrJ_OFisE xKxgPomEgt.tTLuogQM1VXXu770zQ.FP0.gYYzsViQ.uS1CYGpruq6DWvmn0 AQ4ux3u4.yNQROB_MigYG7tNZh6vaKVlP9g6BCorMyyJhyB2mpwau5Eg- Received: from [66.129.224.36] by web37902.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 05:36:09 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 05:36:09 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF20F02.9000700@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1061897651-1307709369=:40312" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:36:12 -0000 --0-1061897651-1307709369=:40312 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Its policy that we would not like to have that kind of meshiness. I am sure= you would not argue about the policy of an operator. =A0 Prem --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 7:33 AM > Sorry about that - The idea of iBGP sessions between PE and ASBR etc > does not fit our needs, but thanks for the very innovative advise. Can you please elaborate why the idea of adding iBGP sessions between PE an= d ASBR etc does not fit your needs ? Thx, R. --0-1061897651-1307709369=:40312 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Its policy that we would not like to hav= e that kind of meshiness. I am sure you would not argue about the policy of= an operator.
 
Prem

--- On Fri, 6/10/11, Robert Raszuk <raszuk@cisco.= com> wrote:

From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 7:33 AM


> Sorry about that - The idea of iBGP session= s between PE and ASBR etc
> does not fit our needs, but thanks for th= e very innovative advise.

Can you please elaborate why the idea of a= dding iBGP sessions between PE and ASBR etc does not fit your needs ?
Thx,
R.

--0-1061897651-1307709369=:40312-- From raszuk@cisco.com Fri Jun 10 05:52:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E3221F84F3 for ; Fri, 10 Jun 2011 05:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCUTdPuvQkDq for ; Fri, 10 Jun 2011 05:52:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8A21A21F84D2 for ; Fri, 10 Jun 2011 05:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1624; q=dns/txt; s=iport; t=1307710320; x=1308919920; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7YrvE4boG4hZf4OwWWivf7Gzu8BokzVq15HrlhXCNLI=; b=bGpkAQj8WtgomnmYRwrQvEfTPcstMbRVykrRhxsJk6fFvHj90bg66II+ LKCnXHhv1Ho0Hv4tgnAt6tlgPE47rDShobDVrl8V/WrHecwZHmoq17hzQ dRqigtsSDEaBArGJ64uULMxMQ4/TA1CJiv1qgFUC1ifwDx4zimk+/rANf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4BABMT8k2rRDoJ/2dsb2JhbABSl1EPjmV3iHKfPYMODwGacoYjBJErhE6EP4ZM X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="463298867" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2011 12:52:00 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5ACpv5x032581; Fri, 10 Jun 2011 12:51:58 GMT Message-ID: <4DF21368.9080707@cisco.com> Date: Fri, 10 Jun 2011 14:51:52 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <870091.40312.qm@web37902.mail.mud.yahoo.com> In-Reply-To: <870091.40312.qm@web37902.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:52:01 -0000 Indeed I will not argue with policy of an operator regardless what type of network he is operating. However let me point out that "this kind of meshiness" is much easier to configure and manage when compared with new overlay of route targets semantics the alternative proposal is all about. With that in mind I would like to hear other operator's opinions about their network policies which would prohibit PE to ASBR iBGP sessions yet in the same time request for per PE manual preference specification of exit points. I think it would also be very helpful to hear experience of those operators which do not use route reflectors at all for their IPv4/IPv6 Internet route distribution. Many thx, R. > Its policy that we would not like to have that kind of meshiness. I am > sure you would not argue about the policy of an operator. > Prem > > --- On *Fri, 6/10/11, Robert Raszuk //* wrote: > > > From: Robert Raszuk > Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection > To: "Reshmi Prem" > Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, > gaurav.thareja@gmail.com, idr@ietf.org, Chintan.Shah@colt.net > Date: Friday, June 10, 2011, 7:33 AM > > > > Sorry about that - The idea of iBGP sessions between PE and ASBR etc > > does not fit our needs, but thanks for the very innovative advise. > > Can you please elaborate why the idea of adding iBGP sessions > between PE and ASBR etc does not fit your needs ? > > Thx, > R. > From reshmi_prem@yahoo.com Fri Jun 10 05:59:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E86311E807C for ; Fri, 10 Jun 2011 05:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.906 X-Spam-Level: X-Spam-Status: No, score=0.906 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe0Ey217gnKE for ; Fri, 10 Jun 2011 05:59:48 -0700 (PDT) Received: from nm7.bullet.mail.sp2.yahoo.com (nm7.bullet.mail.sp2.yahoo.com [98.139.91.77]) by ietfa.amsl.com (Postfix) with SMTP id C5AD711E8077 for ; Fri, 10 Jun 2011 05:59:47 -0700 (PDT) Received: from [98.139.91.68] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jun 2011 12:59:47 -0000 Received: from [98.139.91.25] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jun 2011 12:59:47 -0000 Received: from [127.0.0.1] by omp1025.mail.sp2.yahoo.com with NNFMP; 10 Jun 2011 12:59:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 737023.40086.bm@omp1025.mail.sp2.yahoo.com Received: (qmail 38067 invoked by uid 60001); 10 Jun 2011 12:59:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307710787; bh=20v3I1As+YnRKWP+m4HY3c0KD7dQgj4lhQeJsOXMo4c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SugDmWV96Lj945LqLdPITatNYkBgsfWhoHQTVJeGLykFt52qKF6LmPJ9lT+Dh8iIcCLYiO1OxtVqc97W/Tv9E3638ljpnUFBj7ntpDOyjlX93i3taQqpnUfmqROZSJYZ2/M9cmu5JeHXGt8kV2TtEX5ebZNtE3SyEeb7WzyYXtY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=D+V31/glvFWUrYkrKlgFYqCmi6WwFwmXAOo1+nha+ENw3wXfT5g63fyCGELTe0hXiww4DQ/MSmJVq0U00CuB1IUyJoMIgomL4fmqKKX/fq2eIeu53aDVGOwLi4mQ5GkPHLu90SpWELQdGcmNebj/sQypetcrRZuEu5S+HtFvOVM=; Message-ID: <84094.24987.qm@web37908.mail.mud.yahoo.com> X-YMail-OSG: Wv6tEOAVM1ngqAK94dcsKLG0WsD4dIMWF7UttmVfDaABmRj KnBjs061JOXsiv6LwPSN5nJSPwtTyP4AozOq4cd8.qKFCGk2Ube6pePZHUpa 9XJqv6u3MXfHLcmPqeF_q5DISx_.riH.l.pKRdzn6OqTDKp8wvgwIBkphlG5 Dbsmv6k97R3w2o6zNmlMxsCyCPYlSXQGlz.B7kpSA5zd1LDMCpZhklJg1mMY vmLg3kiSDbkY9K3uOw4.CbrERNCk2qlC3ScdgjcIxLBEKlVTcIPoouTenurL bDmvuKX1Kd67Kw1UOMUr7cvaozOvCg0ke9Pn2g4faOkVcn18YYpkBgdJEuvc lksVaVnTX.K5KmfFdgLeOn6OpXmAMuydf7vuP6ha.kRGA2jB655hqsX1MgzH qKRc1QEPuu5klGEqwIK3but0XpsszCE45lvlz3CAT6zsDCaeC8A6iFRL2a71 5sVuyE9sknm62dLKRjnr5XPaZGmpA5Alc0iWidkVUGHC39j1FZqYM1j3wMwm Y201uvw1jK9AVtITtMelwKq3Eclmo Received: from [217.43.52.160] by web37908.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 05:59:46 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 05:59:46 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF21368.9080707@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-212229696-1307710786=:24987" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:59:49 -0000 --0-212229696-1307710786=:24987 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Good that are not arguing on that.=20 =A0 Policies are always not about operations and management. There are other re= asons as well. I am sure you will hear about our specific needs or have alr= eady heard from your account teams. =A0 One may argue as to why not place a RR in every POP with an ASBR, and handl= e the iBGP sessions so that the closest IGP path is always provided to the = PE. So why did you write an ORR draft?? I presume to cater to certain set o= f requirements which come with some given contraints. =A0 Robert, understand that operators are unique in some sense or the other. Wh= at you deem as less important may be important to us. Our business needs te= chnology to support revenues and thats the bottomline, not the vice versa.= =20 =A0 So dont start becoming the advocate on how an operator should define needs = or which needs are reasonable. =A0 Prem =A0 =A0 --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 7:51 AM Indeed I will not argue with policy of an operator regardless what type=20 of network he is operating. Good. However let me point out that "this kind of meshiness" is much easier to=20 configure and manage when compared with new overlay of route targets=20 semantics the alternative proposal is all about. Policies are always not about operations and management. There are other re= asons as well.=20 With that in mind I would like to hear other operator's opinions about=20 their network policies which would prohibit PE to ASBR iBGP sessions yet=20 in the same time request for per PE manual preference specification of=20 exit points. I think it would also be very helpful to hear experience of those=20 operators which do not use route reflectors at all for their IPv4/IPv6=20 Internet route distribution. Many thx, R. > Its policy that we would not like to have that kind of meshiness. I am > sure you would not argue about the policy of an operator. > Prem > > --- On *Fri, 6/10/11, Robert Raszuk //* wrote: > > >=A0 =A0=A0=A0From: Robert Raszuk >=A0 =A0=A0=A0Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-ref= lection >=A0 =A0=A0=A0To: "Reshmi Prem" >=A0 =A0=A0=A0Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, >=A0 =A0=A0=A0gaurav.thareja@gmail.com, idr@ietf.org, Chintan.Shah@colt.net >=A0 =A0=A0=A0Date: Friday, June 10, 2011, 7:33 AM > > >=A0 =A0 =A0 > Sorry about that - The idea of iBGP sessions between PE and = ASBR etc >=A0 =A0 =A0 > does not fit our needs, but thanks for the very innovative a= dvise. > >=A0 =A0=A0=A0Can you please elaborate why the idea of adding iBGP sessions >=A0 =A0=A0=A0between PE and ASBR etc does not fit your needs ? > >=A0 =A0=A0=A0Thx, >=A0 =A0=A0=A0R. > --0-212229696-1307710786=:24987 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Good that are not arguing on that.=20
 
Policies are always not about operations and managem= ent. There are other reasons as well. I am sure you will hear about our spe= cific needs or have already heard from your account teams.
 
One may argue as to why not place a RR in every POP = with an ASBR, and handle the iBGP sessions so that the closest IGP path is = always provided to the PE. So why did you write an ORR draft?? I presume to= cater to certain set of requirements which come with some given contraints= .
 
Robert, understand that operators are unique in some= sense or the other. What you deem as less important may be important to us= . Our business needs technology to support revenues and thats the bottomlin= e, not the vice versa.
 
So dont start becoming the advocate on how an operat= or should define needs or which needs are reasonable.
 
Prem
 
 


--- On Fri, 6/10/11, Robert R= aszuk <raszuk@cisco.com> wrote:

From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 7:51 AM


Indeed I will not argue with policy of an operat= or regardless what type
of network he is operating.
Good.

However let me point out that "this kind of mesh= iness" is much easier to
configure and manage when compared with new ov= erlay of route targets
semantics the alternative proposal is all about.=
Policies are always not about operations and managem= ent. There are other reasons as well.

With that in mind I would like to hear other ope= rator's opinions about
their network policies which would prohibit PE t= o ASBR iBGP sessions yet
in the same time request for per PE manual pre= ference specification of
exit points.

I think it would also be v= ery helpful to hear experience of those
operators which do not use rout= e reflectors at all for their IPv4/IPv6
Internet route distribution.
Many thx,
R.


> Its policy that we would not like to h= ave that kind of meshiness. I am
> sure you would not argue about the= policy of an operator.
> Prem
>
> --- On *Fri, 6/10/11, = Robert Raszuk /<raszuk@cisco.com>/* wrote:
>
>
>     From: Rober= t Raszuk <raszuk@cisco.com>
>  &= nbsp;  Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-= reflection
>     To: "Reshmi Prem" <reshmi_prem@yahoo.com>
>&= nbsp;    Cc: vjos= eph@juniper.net, bruno.decraene@orange-ftgroup.com,
>   = ;  gaurav.th= areja@gmail.com, idr@ietf.org, Chintan.Shah@colt.net
>     = Date: Friday, June 10, 2011, 7:33 AM
>
>
>    &= nbsp; > Sorry about that - The idea of iBGP sessions between PE and ASBR= etc
>      > does not fit our needs, but thanks fo= r the very innovative advise.
>
>     Can y= ou please elaborate why the idea of adding iBGP sessions
>  &nbs= p;  between PE and ASBR etc does not fit your needs ?
>
= >     Thx,
>     R.
>= ;

--0-212229696-1307710786=:24987-- From reshmi_prem@yahoo.com Fri Jun 10 06:08:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AD711E8130 for ; Fri, 10 Jun 2011 06:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr7onKlUe+w4 for ; Fri, 10 Jun 2011 06:08:02 -0700 (PDT) Received: from nm15-vm0.bullet.mail.bf1.yahoo.com (nm15-vm0.bullet.mail.bf1.yahoo.com [98.139.212.254]) by ietfa.amsl.com (Postfix) with SMTP id F079811E80F8 for ; Fri, 10 Jun 2011 06:08:01 -0700 (PDT) Received: from [98.139.212.151] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 13:07:58 -0000 Received: from [98.139.212.226] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 13:07:58 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 10 Jun 2011 13:07:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 808537.68281.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 51182 invoked by uid 60001); 10 Jun 2011 13:07:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307711278; bh=513QY9+BlvYBYslMVvYEAfuYZRMf7NRgdnKdigdDOms=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4bYbcDYPrdE76eBGe5nmzCo3ESGDtTSoHMwa1hbEzYVyZztGdw6ppfe4RMcaYP18QuHC48QZGw+3duWuA1UddbksXdT1JhSQp9KLZbGaYPj+naEyDv9lSLaWC2odx9cEha+yXNgETcd/UN0rrAKSTNFlGymWagpP8UnLGV/AYlM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jjHj+1Y/d0tiV4PVyMLpH4sN//N/ZCrhR40WbMVIJC285luhzkvCFaUJCMuBbGL+kk5GznqWhIpamtS8g5cINIhre6iz8ihy6o5W0QUtD4wUX1juM0tI6qFlOge8jsZB8ZsJ8NPetQGgt/tcPAhLuQJzf8ojC2HgSBDsRZM3tdY=; Message-ID: <23097.50592.qm@web37903.mail.mud.yahoo.com> X-YMail-OSG: dV7Vs0cVM1ljRjw9L793i0k8l6d_o.3RvdSV_kqhhdpPFUS Q5BjZ2GQYA07jdDWacHHeY49eezgbEcF8ZSglnLaZrXEDk4M7NxsDr3Ih9.Z ymCBVOgjvK.aAim2Gx45mTN2yGNKXQaG6GcLsGtNyK3WKrnyOu8krlqyC4Oc cy3gqhzaiVunTxl6vBZc6WymoiW3cWGCZa9dWE1dO6z9pZRq.VA1uKEqj5iF njQoMeBzaaff5JFGM7krVCc1wSes.UTT6MkUhnuPeDXmOXW5wfipMY5KuUXY SWjGNU3g.9sWHxX21EYBqiuN7Mkw09JLP763K2kKZgFp16AIkdYGxfUtHM3. 7qA3dZ7wkVRMbquQowWxeXDj4loH4fTO4LxSphJo8QxcmZaiI6SFplnXdR4s yoNFQZkOBWvl9rLGb9pI77s7RtKjoVQMmHVDns.vNkVMjKu6X41OUSj6AC6C GmOQjy2zzTuzPwdEOZu4Iovi3RALJcSL4E79YWfCf9e3JCGeA7lZERF7mOfc j9utrYznQBHFmgcpQYMwGyPUT0Orw Received: from [66.129.224.36] by web37903.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 06:07:57 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 06:07:57 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF21368.9080707@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1257450893-1307711277=:50592" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:08:03 -0000 --0-1257450893-1307711277=:50592 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would like to understand this: =A0 Back to the point, using a NH SAFI if I need three ASBR paths on a PE (let = me call this Premium PE), I do have to modify the admin costs on each of th= ese sets of PEs to each of the ASBR manually to a metric=A0that will influe= nce the RR to announce the best path to the=A0PE. You state multiple paths = can be announced as well - let us say I need 3. Is this using ADD-PATH? If = so how do you compute the best path on ADD-PATH?=20 =A0 --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 7:51 AM Indeed I will not argue with policy of an operator regardless what type=20 of network he is operating. However let me point out that "this kind of meshiness" is much easier to=20 configure and manage when compared with new overlay of route targets=20 semantics the alternative proposal is all about. With that in mind I would like to hear other operator's opinions about=20 their network policies which would prohibit PE to ASBR iBGP sessions yet=20 in the same time request for per PE manual preference specification of=20 exit points. I think it would also be very helpful to hear experience of those=20 operators which do not use route reflectors at all for their IPv4/IPv6=20 Internet route distribution. Many thx, R. > Its policy that we would not like to have that kind of meshiness. I am > sure you would not argue about the policy of an operator. > Prem > > --- On *Fri, 6/10/11, Robert Raszuk //* wrote: > > >=A0 =A0=A0=A0From: Robert Raszuk >=A0 =A0=A0=A0Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-ref= lection >=A0 =A0=A0=A0To: "Reshmi Prem" >=A0 =A0=A0=A0Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, >=A0 =A0=A0=A0gaurav.thareja@gmail.com, idr@ietf.org, Chintan.Shah@colt.net >=A0 =A0=A0=A0Date: Friday, June 10, 2011, 7:33 AM > > >=A0 =A0 =A0 > Sorry about that - The idea of iBGP sessions between PE and = ASBR etc >=A0 =A0 =A0 > does not fit our needs, but thanks for the very innovative a= dvise. > >=A0 =A0=A0=A0Can you please elaborate why the idea of adding iBGP sessions >=A0 =A0=A0=A0between PE and ASBR etc does not fit your needs ? > >=A0 =A0=A0=A0Thx, >=A0 =A0=A0=A0R. > --0-1257450893-1307711277=:50592 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

I would like to= understand this:

&= nbsp;

Back to the point, using a NH SAFI if I need = three ASBR paths on a PE (let me call this Premium PE), I do have to modify= the admin costs on each of these sets of PEs to each of the ASBR manually = to a metric that will influence the RR to announce the best path to th= e PE. You state multiple paths can be announced as well - let us say I= need 3. Is this using ADD-PATH? If so how do you compute the best path on = ADD-PATH?


 
--- On Fri, 6/10/11, Robert Raszuk <raszuk@cisco.com><= /B> wrote:

From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 7:51 AM


Indeed I will not argue with policy of an operat= or regardless what type
of network he is operating.

However let = me point out that "this kind of meshiness" is much easier to
configure = and manage when compared with new overlay of route targets
semantics th= e alternative proposal is all about.

With that in mind I would like = to hear other operator's opinions about
their network policies which wo= uld prohibit PE to ASBR iBGP sessions yet
in the same time request for = per PE manual preference specification of
exit points.

I think i= t would also be very helpful to hear experience of those
operators whic= h do not use route reflectors at all for their IPv4/IPv6
Internet route= distribution.

Many thx,
R.


> Its policy that we wo= uld not like to have that kind of meshiness. I am
> sure you would no= t argue about the policy of an operator.
> Prem
>
> --- On *Fri, 6/10/11, Robert Raszuk /<raszuk@cisco.com>/* wrote:
>
>
>   &= nbsp; From: Robert Raszuk <ras= zuk@cisco.com>
>     Subject: Re: [Idr] dr= aft-vinod-lavallee-bgp-optimal-route-reflection
>    &= nbsp;To: "Reshmi Prem" <r= eshmi_prem@yahoo.com>
>     Cc: vjoseph@juniper.net, bruno.decraene@orange= -ftgroup.com,
>     gaurav.thareja@gmail.com, idr@ietf.org, Chintan.Shah@colt.net
>     Date: Friday, J= une 10, 2011, 7:33 AM
>
>
>      > Sorr= y about that - The idea of iBGP sessions between PE and ASBR etc
>&nb= sp;     > does not fit our needs, but thanks for the very inno= vative advise.
>
>     Can you please elabo= rate why the idea of adding iBGP sessions
>     b= etween PE and ASBR etc does not fit your needs ?
>
>     = ;Thx,
>     R.
>

=
--0-1257450893-1307711277=:50592-- From raszuk@cisco.com Fri Jun 10 06:12:10 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F8411E817B for ; Fri, 10 Jun 2011 06:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nFHmIyuZ5wu for ; Fri, 10 Jun 2011 06:12:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3E97411E80F8 for ; Fri, 10 Jun 2011 06:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1537; q=dns/txt; s=iport; t=1307711525; x=1308921125; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vWUTKzPlQCFZfSbFgWfZu/MyW/vd9kS5E/O3Y93JIaY=; b=mrQkw/vtmwx0VIHgqVkaOG/K/n/Xori0QS8Tbmx9UEzhs1QbS8I08sqk 0op8HE6m0KD5pxw2gteLhggeUL2MYOBX4hcxGftTuO2hhKY7QauFXo5rE 00hvanux85OJxOvPDKtvh7QmpDl3bCaWM1fAsH3GZpd6E3VRJX1Pp9nnu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEYX8k2rRDoI/2dsb2JhbABSpkV3iHKfKoMODwGacIYjBJErhE6LCw X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="374201112" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2011 13:12:05 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5ADC2VH020895; Fri, 10 Jun 2011 13:12:03 GMT Message-ID: <4DF2181D.3030203@cisco.com> Date: Fri, 10 Jun 2011 15:11:57 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <84094.24987.qm@web37908.mail.mud.yahoo.com> In-Reply-To: <84094.24987.qm@web37908.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:12:10 -0000 > One may argue as to why not place a RR in every POP with an ASBR, and > handle the iBGP sessions so that the closest IGP path is always provided > to the PE. So why did you write an ORR draft?? So I guess you have not been at Nanogs nor RIPEs nor APRICOT meetings where I clearly demonstrated that the best place of RR remains to be in data path on the POP to core boundary (just like it was traditionally recommended). And that design is still deployed and works great in many networks today. Only due to some networks .. where PE-PE or PE-ASBR is all tunneled .. RRs no longer are in the data path. Those networks try to move them to core locations and that's the base of ORR proposal. IDR WG ORR draft is not to recommend new way of route reflection. Very much contrary .. it is designed to assure hot potato routing only for those operators which need it and which use pure control plane RRs. With addition of NH-SAFI it also addresses needs of those operators which need to overwrite what IGP SPF product would be. > I presume to cater to > certain set of requirements which come with some given contraints. > Robert, understand that operators are unique in some sense or the other. > What you deem as less important may be important to us. Our business > needs technology to support revenues and thats the bottomline, not the > vice versa. And I am here to judge an importance of your choice. But in order to help to meet your goals I am here to better understand your needs. R. From reshmi_prem@yahoo.com Fri Jun 10 06:18:44 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0C611E80F8 for ; Fri, 10 Jun 2011 06:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlwljDCuFvtt for ; Fri, 10 Jun 2011 06:18:42 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ac4.yahoo.com (nm3-vm0.bullet.mail.ac4.yahoo.com [98.139.53.204]) by ietfa.amsl.com (Postfix) with SMTP id 8654B1F0C54 for ; Fri, 10 Jun 2011 06:18:41 -0700 (PDT) Received: from [98.139.52.188] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 13:18:38 -0000 Received: from [98.139.52.166] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 13:18:38 -0000 Received: from [127.0.0.1] by omp1049.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 13:18:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 245118.43416.bm@omp1049.mail.ac4.yahoo.com Received: (qmail 57215 invoked by uid 60001); 10 Jun 2011 13:18:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307711917; bh=yYx43rxcLQN43zvQwQ3piZcfs/O+du8xkcCNrrReOLo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ydb17GzT75BunGpxp7gLmYi/8BsNjf2hnSOutHweCugaqmsXXvc5eETDVp+DaBED1fi6FLr5EAFGttAXKRuwuDDwXrQSE11UjZZeI54wLKU1C4s3jthH9Kam1KbTHBij5b+S1kQQO6HSRbO0uLxwpyvYXQAnF8CZkeySFv1z6Tk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=uX0z1RcfDHRVlcMdIPTILHgI/QCVLJW+guzZEFCr/5V1LqdDgZdTdNMXcmwiW2uR7L8i7BOrm8fy4Zgswtx84S3YTrq+jlEk33kcwoVf4c6KINuy+fiWsnQQ9beLSDvT6XZO/AeW09JtU6sllNjMIzGvysvNZsl2pJYZnqG8wYM=; Message-ID: <3042.15614.qm@web37903.mail.mud.yahoo.com> X-YMail-OSG: OQcTEAoVM1lFAmvUvPg_LypsVB15NIdkeqEyifjmIMFjHnq e0iVLnx8l6X7NcqMZChOmD8EJ2tikd3NDjtvRr9CbJpXFQtj6MlM5kvrSc9h LV.ZSYkQaRl5HdXYoV1vw05WTGCjxGaXelGoUyxH7GBCMioqpjLQxGeQb6tW MlKv53GTs685v4lIVlNvgMpsavOipFnYPuNH992v2C5LgiP2W1fZS62csW5i HKgtQ41p0bL1RgBoAjei2I1jmehhaCOb1txihfqADggoYmV8jvC7HO.GSrHw QRboTw5O5wpq3CxcEbk9gzScAdrRfZgKXeRnJ10y0qvqCOk2V2ucHD6OreMW 6Do7PLcjZUNFpQVsNhThF_w3_NaNnRpfPKmFXwdQB2l_qFrTj4zS8AcKCJk1 V8Hp.9Jqv5lB0 Received: from [66.129.224.36] by web37903.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 06:18:36 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 06:18:36 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF2181D.3030203@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1998664509-1307711916=:15614" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:18:44 -0000 --0-1998664509-1307711916=:15614 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I am not arguing about whether you are the messiah of a revolution in BGP R= oute Reflection or not. =A0 If I use an RR (not in the forwarding plane imagine) at every POP which has= an ASBR (imagine there are 10 ASBR POPs). If I have each PE in every POP p= eer with their closest RR - which is the RR in a POP which has the closest = IGP metric in regard to that PE. Would'nt I be ensured that this PE will de= finitely receieve the ASBR path that has the closest IGP metric?? =A0 Prem --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 8:11 AM > One may argue as to why not place a RR in every POP with an ASBR, and > handle the iBGP sessions so that the closest IGP path is always provided > to the PE. So why did you write an ORR draft?? So I guess you have not been at Nanogs nor RIPEs nor APRICOT meetings where= I clearly demonstrated that the best place of RR remains to be in data pat= h on the POP to core boundary (just like it was traditionally recommended).= And that design is still deployed and works great in many networks today. Only due to some networks .. where PE-PE or PE-ASBR is all tunneled .. RRs = no longer are in the data path. Those networks try to move them to core loc= ations and that's the base of ORR proposal. IDR WG ORR draft is not to reco= mmend new way of route reflection. Very much contrary .. it is designed to = assure hot potato routing only for those operators which need it and which = use pure control plane RRs. With addition of NH-SAFI it also addresses needs of those operators which n= eed to overwrite what IGP SPF product would be. > I presume to cater to > certain set of requirements which come with some given contraints. > Robert, understand that operators are unique in some sense or the other. > What you deem as less important may be important to us. Our business > needs technology to support revenues and thats the bottomline, not the > vice versa. And I am here to judge an importance of your choice. But in order to help t= o meet your goals I am here to better understand your needs. R. --0-1998664509-1307711916=:15614 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --0-1998664509-1307711916=:15614-- From raszuk@cisco.com Fri Jun 10 06:21:38 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9291F0C51 for ; Fri, 10 Jun 2011 06:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSEpCUP59FhW for ; Fri, 10 Jun 2011 06:21:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1C1F0C56 for ; Fri, 10 Jun 2011 06:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1555; q=dns/txt; s=iport; t=1307712082; x=1308921682; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hDsbrkZl5nhuhZ+PkdJIP8mwruZPL8O5Urntb/hcPns=; b=Io7Ik3fXNyB2gfCITT55VdN+M1VsspxuARnw2NYXp0b+exHXDk2CZJdh JKJEMZgUbr4mobuePoFM1tpkfM86Jyb9QIvjeTYZmfb86qBEgKSS8M6+2 ZEefRq3bgQCif3SgeErgIW6+538n/1a6agVKzDDQp2zgEhCOSy/uFr643 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKAZ8k2rRDoG/2dsb2JhbABSpkV3iHKfIYMODwGacYYjBJErhE6LCw X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="374206576" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2011 13:21:21 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ADLJGD021903; Fri, 10 Jun 2011 13:21:20 GMT Message-ID: <4DF21A4A.2030404@cisco.com> Date: Fri, 10 Jun 2011 15:21:14 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <23097.50592.qm@web37903.mail.mud.yahoo.com> In-Reply-To: <23097.50592.qm@web37903.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:21:38 -0000 Hi Reshmi, > I would like to understand this: Let me try to help .. > Back to the point, using a NH SAFI if I need three ASBR paths on a PE > (let me call this Premium PE), I do have to modify the admin costs on > each of these sets of PEs to each of the ASBR manually to a metric that > will influence the RR to announce the best path to the PE. That is correct. However please notice that this is no more configuration overhead then allocating three RTs on such premium PE in order to advertise them to the RR. In fact metric could be expressed by numerical RT value. That is how you express the local Premium PE policy. And just for completeness such PE policy can be expressed on the PE then signalled by using NH-SAFI to RR or directly on the RR when you are establishing a session between PE-RR. > You state > multiple paths can be announced as well - let us say I need 3. Is this > using ADD-PATH? If so how do you compute the best path on ADD-PATH? Add-path spec deliberately avoids discussion on best path selection rules. Add-path spec is design to represent encoding on how BGP can send you more then single path on the same session. Any application which would like utilize add-path requires separate specification. In this particular case using ORR draft RR when advertising closest exit path, 2nd closest and 3rd closest towards PE can set local pref accordingly to the computed order of paths so PE will select using normal best path selection rules correctly. Best regards, R. From reshmi_prem@yahoo.com Fri Jun 10 06:27:15 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE509E8005 for ; Fri, 10 Jun 2011 06:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpOxUQAEUkiY for ; Fri, 10 Jun 2011 06:27:14 -0700 (PDT) Received: from nm8.bullet.mail.ac4.yahoo.com (nm8.bullet.mail.ac4.yahoo.com [98.139.52.205]) by ietfa.amsl.com (Postfix) with SMTP id 15BE921F8479 for ; Fri, 10 Jun 2011 06:27:14 -0700 (PDT) Received: from [98.139.52.194] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 13:27:10 -0000 Received: from [98.139.52.131] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 13:27:10 -0000 Received: from [127.0.0.1] by omp1014.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 13:27:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 215360.77802.bm@omp1014.mail.ac4.yahoo.com Received: (qmail 60774 invoked by uid 60001); 10 Jun 2011 13:27:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307712428; bh=0lvkCqDyorQqjoJbLY8SWOC+sLVYvwmUy8nURRUIToU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OmtV7mQEjTdBr1HbcG/iwkYaD6lLHm2+spBwQJrOB89/FHpb6nV0qVbQrF0zibdlxCSXXA3bL5Iajwc4MRnHya1sth18Nnl4+Tady+mQGwNqZMmnT5hhxIPygu0/dQISB9BRh+S/MRQT40kQTogBn88WZ00pKHoWDsceIU5CeyU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xDjwM50zSHNM3TpCS3fkdGj1bcTYFEC2PKZFkG0429MDUGgS8VXRXoa/FILLtL0iFaevRx++FwgeyRwZsxOL/exbwWktbc736J//nMC5WE/fgymTx/B9OBg8zlLGnKyVPLyQRVScKJ8Hj9AM93JkDPYbcQeyinB7ao32fSbganE=; Message-ID: <506139.52409.qm@web37903.mail.mud.yahoo.com> X-YMail-OSG: BnBAFL4VM1lbNmjthRBneKb7aaTwhBxY7GbPndJY19C_K_B ViHeZCxgn15q.5p0pATl8_FNqYu8_R6bOCiG6w24IpRA3Gfnf12yua8AS66r 80_mpj9yTb_zbEGgJhCZYX2qtdlGbEGpfabVYPO.JSLNFvrC0LUto_XcjCvs VEKXnr6T8c5AIm4Ez0P5etQJ_Ei6NowxQB9RDdKdlt.ciH4ICvw1G7iQlX.K yPlO8fJWUYpHJoJ5P.B8uPugmDh.he9TlcGS8GoC1FSxB_riUp.4OV4k9Qb9 pfX7rxXdAA57oimYEXT6rS_2ip_x1e.BLn076auGbWmOCh4xLXDOeDeDaFYj AGlr.Fbmpw3zjIZsDOHgli.GAQb7ikHIilkQkRD6druRftkrsQqeQ97ejL.w VL3eGzC.fvMEE Received: from [66.129.224.36] by web37903.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 06:27:08 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 06:27:08 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF21A4A.2030404@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-510030133-1307712428=:52409" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:27:15 -0000 --0-510030133-1307712428=:52409 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Robert, =A0 Let me make sure that we are in sync. =A0 That is correct. However please notice that this is no more configuration o= verhead then allocating three RTs on such premium PE in order to advertise = them to the RR. In fact metric could be expressed by numerical RT value. That is how you express the local Premium PE policy. And just for completen= ess such PE policy can be expressed on the PE then signalled by using NH-SA= FI to RR or directly on the RR when you are establishing a session between = PE-RR. >>>>>>>>>So the configuration is no more complex than the RTC Draft in term= s of number of lines or whatever that is. =A0 In this particular case using ORR draft RR when advertising closest exit pa= th, 2nd closest and 3rd closest towards PE can set local pref accordingly t= o the computed order of paths so PE will select using normal best path sele= ction rules correctly. >>>>>>>>>>>what scheme or what do you use to send three paths? is there a d= raft? i am keen to know if a PE sets a metric to 3 ASBRs as 5,10 and 15. Us= ing NH SAFI how do i tell the RR to send me 3 paths? =A0 Prem --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 8:21 AM Hi Reshmi, > I would like to understand this: Let me try to help .. > Back to the point, using a NH SAFI if I need three ASBR paths on a PE > (let me call this Premium PE), I do have to modify the admin costs on > each of these sets of PEs to each of the ASBR manually to a metric that > will influence the RR to announce the best path to the PE. That is correct. However please notice that this is no more configuration o= verhead then allocating three RTs on such premium PE in order to advertise = them to the RR. In fact metric could be expressed by numerical RT value. That is how you express the local Premium PE policy. And just for completen= ess such PE policy can be expressed on the PE then signalled by using NH-SA= FI to RR or directly on the RR when you are establishing a session between = PE-RR. > You state > multiple paths can be announced as well - let us say I need 3. Is this > using ADD-PATH? If so how do you compute the best path on ADD-PATH? Add-path spec deliberately avoids discussion on best path selection rules. = Add-path spec is design to represent encoding on how BGP can send you more = then single path on the same session. Any application which would like utilize add-path requires separate specifi= cation. In this particular case using ORR draft RR when advertising closest exit pa= th, 2nd closest and 3rd closest towards PE can set local pref accordingly t= o the computed order of paths so PE will select using normal best path sele= ction rules correctly. Best regards, R. --0-510030133-1307712428=:52409 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I am not arguing about whether you are t= he messiah of a revolution in BGP Route Reflection or not.
 
If I use an RR (not in the forwarding plane imagine) at every POP whic= h has an ASBR (imagine there are 10 ASBR POPs). If I have each PE in every = POP peer with their closest RR - which is the RR in a POP which has the clo= sest IGP metric in regard to that PE. Would'nt I be ensured that this PE wi= ll definitely receieve the ASBR path that has the closest IGP metric??
 
Prem

--- On Fri, 6/10/11, Robert Raszuk <raszuk@cisco.= com> wrote:

From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 8:11 AM


> One may argue as to why not place a RR in e= very POP with an ASBR, and
> handle the iBGP sessions so that the clo= sest IGP path is always provided
> to the PE. So why did you write an= ORR draft??

So I guess you have not been at Nanogs nor RIPEs nor AP= RICOT meetings where I clearly demonstrated that the best place of RR remai= ns to be in data path on the POP to core boundary (just like it was traditi= onally recommended). And that design is still deployed and works great in m= any networks today.

Only due to some networks .. where PE-PE or PE-A= SBR is all tunneled .. RRs no longer are in the data path. Those networks t= ry to move them to core locations and that's the base of ORR proposal. IDR = WG ORR draft is not to recommend new way of route reflection. Very much con= trary .. it is designed to assure hot potato routing only for those operato= rs which need it and which use pure control plane RRs.

With addition of NH-SAFI it also addresses needs of those operators which need = to overwrite what IGP SPF product would be.

> I presume to cater = to
> certain set of requirements which come with some given contraint= s.
> Robert, understand that operators are unique in some sense or th= e other.
> What you deem as less important may be important to us. Ou= r business
> needs technology to support revenues and thats the botto= mline, not the
> vice versa.

And I am here to judge an importa= nce of your choice. But in order to help to meet your goals I am here to be= tter understand your needs.

R.
Robert,
 
Let me make sure that we are in sync.
 
That is correct. However please notice that this is no more configurat= ion overhead then allocating three RTs on such premium PE in order to adver= tise them to the RR.

In fact metric could be expressed by numerical = RT value.

That is how you express the local Premium PE policy. And j= ust for completeness such PE policy can be expressed on the PE then signall= ed by using NH-SAFI to RR or directly on the RR when you are establishing a= session between PE-RR.

>>>>>>>>>So the c= onfiguration is no more complex than the RTC Draft in terms of number of li= nes or whatever that is.
 
In this particular case using ORR draft RR when advertising closest ex= it path, 2nd closest and 3rd closest towards PE can set local pref accordin= gly to the computed order of paths so PE will select using normal best path= selection rules correctly.

>>>>>>>>>>= >what scheme or what do you use to send three paths? is there a draft? i= am keen to know if a PE sets a metric to 3 ASBRs as 5,10 and 15. Using NH = SAFI how do i tell the RR to send me 3 paths?
 
Prem
--- On Fri, 6/10/11, Robert Raszuk <raszuk@cisco.com&= gt; wrote:

From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 8:21 AM

Hi Reshmi,

> I would like to understand th= is:

Let me try to help ..

> Back to the point, using a NH = SAFI if I need three ASBR paths on a PE
> (let me call this Premium P= E), I do have to modify the admin costs on
> each of these sets of PE= s to each of the ASBR manually to a metric that
> will influence the = RR to announce the best path to the PE.

That is correct. However ple= ase notice that this is no more configuration overhead then allocating thre= e RTs on such premium PE in order to advertise them to the RR.

In fa= ct metric could be expressed by numerical RT value.

That is how you = express the local Premium PE policy. And just for completeness such PE poli= cy can be expressed on the PE then signalled by using NH-SAFI to RR or dire= ctly on the RR when you are establishing a session between PE-RR.

&g= t; You state
> multiple paths can be announced as well - let us say I need 3. Is this
> using ADD-PATH? If so how do you compute the= best path on ADD-PATH?

Add-path spec deliberately avoids discussion= on best path selection rules. Add-path spec is design to represent encodin= g on how BGP can send you more then single path on the same session.
Any application which would like utilize add-path requires separate specif= ication.

In this particular case using ORR draft RR when advertising= closest exit path, 2nd closest and 3rd closest towards PE can set local pr= ef accordingly to the computed order of paths so PE will select using norma= l best path selection rules correctly.

Best regards,
R.

--0-510030133-1307712428=:52409-- From raszuk@cisco.com Fri Jun 10 06:28:53 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138A19E8008 for ; Fri, 10 Jun 2011 06:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.177 X-Spam-Level: X-Spam-Status: No, score=-10.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwk57lyLaxfG for ; Fri, 10 Jun 2011 06:28:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 95D6C1F0C60 for ; Fri, 10 Jun 2011 06:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=876; q=dns/txt; s=iport; t=1307712532; x=1308922132; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VB+qqkfKhXh5g9QTFxTbJartVFGHnaDUNdAsVV34l10=; b=IHPkc+JmsgzBhj2AN158yyumEtB5rMg2ilGC7Nwu5pvnB/wrxQoyBDZD S8Uj1SPGTb+gufVqWWzeXhSH2p4V/OmsXxWms/ScB049QXhVfx0HGRp6m 8IGEzShaR2Msk7L41iX1iqEnXBBIUUzhZKWaeBM2z+MX4uzt72TCXDTFh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEIb8k2rRDoG/2dsb2JhbABSpkV3iHKfEoMODwGacYYjBJErhE6LCw X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="334353011" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2011 13:28:52 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ADSnKW029607; Fri, 10 Jun 2011 13:28:50 GMT Message-ID: <4DF21C0D.7090500@cisco.com> Date: Fri, 10 Jun 2011 15:28:45 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <3042.15614.qm@web37903.mail.mud.yahoo.com> In-Reply-To: <3042.15614.qm@web37903.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:28:53 -0000 > I am not arguing about whether you are the messiah of a revolution in > BGP Route Reflection or not. Nope I am not a messiah of any sort, but now you know what my initials stand for.... ;-) > If I use an RR (not in the forwarding plane imagine) at every POP which > has an ASBR (imagine there are 10 ASBR POPs). If I have each PE in every > POP peer with their closest RR - which is the RR in a POP which has the > closest IGP metric in regard to that PE. Would'nt I be ensured that this > PE will definitely receieve the ASBR path that has the closest IGP metric?? > Prem Yes you will be ensured under two conditions: - assuming that such RRs reside in the POP which will always have local exit ASBR - that your RR even in the control plane has visibility to the area 0 in the case of hierarchical IGP (practically is an ABR). Thx, R. From raszuk@cisco.com Fri Jun 10 06:36:50 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA5111E8164 for ; Fri, 10 Jun 2011 06:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9fRoJBWPiz5 for ; Fri, 10 Jun 2011 06:36:49 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id C6EB411E814D for ; Fri, 10 Jun 2011 06:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2085; q=dns/txt; s=iport; t=1307713009; x=1308922609; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=aNz204OD2zJuHtMDVLx3Inl6OVT9N7H2uV5brIGfdKU=; b=ZtqHSJLzS46IGHOeM9O1aZH49+1CMclRB8ufHN3NIEPzxNbzrkECGHWc Tz/r+685/KWA92UHTiLx2Ur0VZoGKVSfmLfzWtuYQZTLtP1GbEPhwgrdY +NRdVJiInJkX0QJe0rbrc/XTP+qOQD1LURuOV4MaBaz0Fu/9df4rx3GFw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB0d8k2rRDoG/2dsb2JhbABSpkV3iHKfD4MODwGacYYjBJErhE6LCw X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="374214909" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2011 13:36:49 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ADakdK001939; Fri, 10 Jun 2011 13:36:47 GMT Message-ID: <4DF21DEA.1040001@cisco.com> Date: Fri, 10 Jun 2011 15:36:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <506139.52409.qm@web37903.mail.mud.yahoo.com> In-Reply-To: <506139.52409.qm@web37903.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:36:50 -0000 Reshmi, > Robert, > Let me make sure that we are in sync. Very good idea ! > That is correct. However please notice that this is no more > configuration overhead then allocating three RTs on such premium PE in > order to advertise them to the RR. > > In fact metric could be expressed by numerical RT value. > > That is how you express the local Premium PE policy. And just for > completeness such PE policy can be expressed on the PE then signalled by > using NH-SAFI to RR or directly on the RR when you are establishing a > session between PE-RR. > > >>>>>>>>>So the configuration is no more complex than the RTC Draft in > terms of number of lines or whatever that is. Yes but _only_ from PE point of view. Essentially if you are asking for manual policy you need to express it somewhere in the network - no way around that. But with NH-SAFI there is _no change_ to any BGP operation on the RR, no RTC, no applying any new communities on the ASBR. So if we are to be in sync let's consider full picture. > In this particular case using ORR draft RR when advertising closest exit > path, 2nd closest and 3rd closest towards PE can set local pref > accordingly to the computed order of paths so PE will select using > normal best path selection rules correctly. > > >>>>>>>>>>>what scheme or what do you use to send three paths? is there > a draft? i am keen to know if a PE sets a metric to 3 ASBRs as 5,10 and > 15. Using NH SAFI how do i tell the RR to send me 3 paths? > Prem In today's implementations of add-path it is local configuration on the RR when you specify number of add-path eligible paths. When we implement NH-SAFI draft RR will ask PE for metrics to all next hops let's say 10 it has in the BGP table. Then PE will reply with metric to 3 of them say 5, 10, 15 and metric 0 to the rest of them which means I am not interested to hear about them. Hence RR will only send 3 paths to such PE without any need to manual configure the number on the RR side per POP or per client. Best regards, R. From reshmi_prem@yahoo.com Fri Jun 10 06:58:34 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B79111E8135 for ; Fri, 10 Jun 2011 06:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyIcQcs+6+iL for ; Fri, 10 Jun 2011 06:58:34 -0700 (PDT) Received: from nm11.bullet.mail.ne1.yahoo.com (nm11.bullet.mail.ne1.yahoo.com [98.138.90.74]) by ietfa.amsl.com (Postfix) with SMTP id B885711E80CA for ; Fri, 10 Jun 2011 06:58:33 -0700 (PDT) Received: from [98.138.90.55] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 13:58:30 -0000 Received: from [98.138.89.246] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 13:58:30 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 13:58:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 513924.54579.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 53935 invoked by uid 60001); 10 Jun 2011 13:58:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307714306; bh=DD3MsmgNdMJsgiyMyWggi8EoS7UCqQx7EBDv52znMIA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j9CM6EpWROnBZu9S3XjyPKnEYJRqzcYcXYjP/UpKU8z3nTPIqTl5zC7cPCeYkgh6cmCleTwWPBZRnMpHMMH2wiSJrld/DxY8fwA121iX0A2fHmY2mKNgGUE2JO1MD4bbRqKkfx91G6DI/4tqo8EU20pSF6NxVCQw/UbC5yurXH0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jgJ9COvsHZujMl/NTUaQHzmhIQL7onieioRljNLxKNhZx6NcuGl/aMcOaQQgFZ4XTBXmicH/R73sZNDpuAdqR4RXIyA8oPT1jVDc/RwAcbmMRc1W5IEnku+Ho3ihJ0f8dAnGOJE1hwHsGmwDWHm0QB4q6S65TTeGaTxz3Fi3kZI=; Message-ID: <55919.44959.qm@web37901.mail.mud.yahoo.com> X-YMail-OSG: Q.lHS7oVM1nQkZMYCxWkNflZZ46gs6aquZmBd2k_NbACEQ0 4KU.Ob8n_YDIZBPP0Z.tioG3Go70QSqj1h0ru14gSHbkKlhrf7ekVCd0QJzG WRMhPBNgCshrYKuHULsrBJnLeueZFl8MTNmRrk9jQaEA1WFgzMs_PA8rfuKn F9mqEgyYioqNc76I27mDm7iO845IXizGm34DlsTAgkSPNXeXAiXOvUkgfBG. BS1cj4CJpkmpmm3oZ1oULD5w8RjL5us7pFavfhBXPMUlScHWL9l_DVSyBtjp GGVuOLbXctq0WRwK3B2WIjJPFDgRRrWHHXGXvyGiqNvCNjU9DeJrexe60iaA bQGaVuQK8uNxUp7WHZ6XSUJZwO7aGlypmzO_MBk806sMs7ln.btLt3qY- Received: from [66.129.224.36] by web37901.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 06:58:25 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 06:58:25 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF21C0D.7090500@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-294237048-1307714305=:44959" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:58:34 -0000 --0-294237048-1307714305=:44959 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Absolutely. So I dont need an ORR at all. --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 8:28 AM > I am not arguing about whether you are the messiah of a revolution in > BGP Route Reflection or not. Nope I am not a messiah of any sort, but now you know what my initials stan= d for.... ;-) > If I use an RR (not in the forwarding plane imagine) at every POP which > has an ASBR (imagine there are 10 ASBR POPs). If I have each PE in every > POP peer with their closest RR - which is the RR in a POP which has the > closest IGP metric in regard to that PE. Would'nt I be ensured that this > PE will definitely receieve the ASBR path that has the closest IGP metric= ?? > Prem Yes you will be ensured under two conditions: - assuming that such RRs reside in the POP which will always have local =A0 exit ASBR - that your RR even in the control plane has visibility to the area 0 =A0 in the case of hierarchical IGP (practically is an ABR). Thx, R. --0-294237048-1307714305=:44959 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Absolutely. So I dont need an ORR at all.
=
--- On Fri, 6/10/11, Robert Raszuk <raszuk@cisco.com> wrote:

From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 8:28 AM


> I am not arguing about whether you are the = messiah of a revolution in
> BGP Route Reflection or not.

Nope= I am not a messiah of any sort, but now you know what my initials stand fo= r.... ;-)

> If I use an RR (not in the forwarding plane imagine) = at every POP which
> has an ASBR (imagine there are 10 ASBR POPs). If= I have each PE in every
> POP peer with their closest RR - which is = the RR in a POP which has the
> closest IGP metric in regard to that = PE. Would'nt I be ensured that this
> PE will definitely receieve the= ASBR path that has the closest IGP metric??
> Prem

Yes you wi= ll be ensured under two conditions:

- assuming that such RRs reside = in the POP which will always have local
  exit ASBR

- that y= our RR even in the control plane has visibility to the area 0
  in = the case of hierarchical IGP (practically is an ABR).

Thx,
R.
--0-294237048-1307714305=:44959-- From reshmi_prem@yahoo.com Fri Jun 10 07:02:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A58C11E81B3 for ; Fri, 10 Jun 2011 07:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie2mL0l7kiGE for ; Fri, 10 Jun 2011 07:02:38 -0700 (PDT) Received: from nm12.bullet.mail.ac4.yahoo.com (nm12.bullet.mail.ac4.yahoo.com [98.139.52.209]) by ietfa.amsl.com (Postfix) with SMTP id 6B2D111E81B2 for ; Fri, 10 Jun 2011 07:02:38 -0700 (PDT) Received: from [98.139.52.193] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 14:02:35 -0000 Received: from [98.139.52.142] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 14:02:35 -0000 Received: from [127.0.0.1] by omp1025.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 14:02:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 449659.48944.bm@omp1025.mail.ac4.yahoo.com Received: (qmail 43246 invoked by uid 60001); 10 Jun 2011 14:02:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307714554; bh=Xvg5ir3Ky3BpltWfqx9Rcmjr/MyZ1KdsKhQXxH0xxoU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gMGs0sUmhMr8wqC7TSu9Ha9eAs5cUQYpOn2OOeD7/Cgx6lJbrnzk8/rRgNhsWywVLb2QycF+NwZrK7eyC4FcmN4BDg6YdHpzHIFIMKVW1mx+71KYb9SX/4eYZHn5drOTZUzv+oSIuttZHIDrnhaBdO/bd/9+hyFKRArDm3QAdJQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YbjCXzUJ2Ho5vFg5VBJ3xkGoNrgS9SpcSa7dY1c83psknZpR2M8Qzq4H9dvcgFGcnV5dloMESUOld7GgwWPPBjKqn7t+oOGQ9oVBU83YlbCnHvO4v2jhIp3v1s79ppGCj/T6qBiNKVoMXdG7oX/flF8Ab1A6eIC7jJecCRRS8qE=; Message-ID: <924216.12659.qm@web37907.mail.mud.yahoo.com> X-YMail-OSG: .V3JvGUVM1l_Fm2.I60lekh.sDF7RxVJ0WJTuGNGEZIOzLC mgQyxCndJomH3e2GFzrZw2JtxV0oaf.qRf_Xp7O5Ie4c9lhRm4AIiQo_eMWm Ip2gwZ6Ckk4Drp7T3gZ4sg8Zx2mmXZmil8E..tch.cS6hAQdIeLBKVIp3N_W y.X7IRFw0RVPNlKNsR9EPtYYDjkFBnQM.YfhKzzkAGhNEXrYiczZZlGmF1ik bVse0c6Nm8z8OdPsRDnONQ3Hp4j_UDxobQch39MYnFsuyx_kaO1DXf.5hTRR YMgGk1c.ArRteo_TOK.bky3quD.aKFtsSemzJoHve9fJz2vhP7Vj5ub5qkRi 0TkqkW.keX3p1911l30dhqmG4LEVpNZwr4alyQQ2a.6ecKCrPC.j5kmNPzah jZwluRFiBqQmfAg-- Received: from [66.129.224.36] by web37907.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 07:02:34 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 07:02:34 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF21DEA.1040001@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-621987539-1307714554=:12659" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:02:39 -0000 --0-621987539-1307714554=:12659 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In this particular case using ORR draft RR when advertising closest exit pa= th, 2nd closest and 3rd closest towards PE can set local pref accordingly t= o the computed order of paths so PE will select using normal best path sele= ction rules correctly. >>>>>>>>>>>How does this tie in to the whole story now? Are you saying that= in your ORR proposal I have configure manual policies on the RR for each P= E that has these needs , by statically defining each NH modifying local-pre= f on the RR towards each PE? =A0 >>>>>>>> What happens if all the three NHs disappear or fail? =A0 Prem =A0 --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 8:36 AM Reshmi, > Robert, > Let me make sure that we are in sync. Very good idea ! > That is correct. However please notice that this is no more > configuration overhead then allocating three RTs on such premium PE in > order to advertise them to the RR. >=20 > In fact metric could be expressed by numerical RT value. >=20 > That is how you express the local Premium PE policy. And just for > completeness such PE policy can be expressed on the PE then signalled by > using NH-SAFI to RR or directly on the RR when you are establishing a > session between PE-RR. >=20 >=A0 >>>>>>>>>So the configuration is no more complex than the RTC Draft in > terms of number of lines or whatever that is. Yes but _only_ from PE point of view. Essentially if you are asking for man= ual policy you need to express it somewhere in the network - no way around = that. But with NH-SAFI there is _no change_ to any BGP operation on the RR, no RT= C, no applying any new communities on the ASBR. So if we are to be in sync = let's consider full picture. > In this particular case using ORR draft RR when advertising closest exit > path, 2nd closest and 3rd closest towards PE can set local pref > accordingly to the computed order of paths so PE will select using > normal best path selection rules correctly. >=20 >=A0 >>>>>>>>>>>what scheme or what do you use to send three paths? is ther= e > a draft? i am keen to know if a PE sets a metric to 3 ASBRs as 5,10 and > 15. Using NH SAFI how do i tell the RR to send me 3 paths? > Prem In today's implementations of add-path it is local configuration on the RR = when you specify number of add-path eligible paths. When we implement NH-SAFI draft RR will ask PE for metrics to all next hops= let's say 10 it has in the BGP table. Then PE will reply with metric to 3 = of them say 5, 10, 15 and metric 0 to the rest of them which means I am not= interested to hear about them. Hence RR will only send 3 paths to such PE without any need to manual confi= gure the number on the RR side per POP or per client. Best regards, R. --0-621987539-1307714554=:12659 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In this particular case using ORR draft R= R when advertising closest exit path, 2nd closest and 3rd closest towards P= E can set local pref accordingly to the computed order of paths so PE will = select using normal best path selection rules correctly.


From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 8:36 AM

Reshmi,

> Robert,
> Let me make sure= that we are in sync.

Very good idea !

> That is correct. = However please notice that this is no more
> configuration overhead t= hen allocating three RTs on such premium PE in
> order to advertise t= hem to the RR.
>
> In fact metric could be expressed by numeri= cal RT value.
>
> That is how you express the local Premium PE= policy. And just for
> completeness such PE policy can be expressed = on the PE then signalled by
> using NH-SAFI to RR or directly on the = RR when you are establishing a
> session between PE-RR.
>
&= gt;  >>>>>>>>>So the configuration is no mo= re complex than the RTC Draft in
> terms of number of lines or whatev= er that is.

Yes but _only_ from PE point of view. Essentially if you= are asking for manual policy you need to express it somewhere in the network - no way around that.

But with NH-SAFI there is _no change_= to any BGP operation on the RR, no RTC, no applying any new communities on= the ASBR. So if we are to be in sync let's consider full picture.

&= gt; In this particular case using ORR draft RR when advertising closest exi= t
> path, 2nd closest and 3rd closest towards PE can set local pref> accordingly to the computed order of paths so PE will select using> normal best path selection rules correctly.
>
>  &= gt;>>>>>>>>>>what scheme or what do you use t= o send three paths? is there
> a draft? i am keen to know if a PE set= s a metric to 3 ASBRs as 5,10 and
> 15. Using NH SAFI how do i tell t= he RR to send me 3 paths?
> Prem

In today's implementations of= add-path it is local configuration on the RR when you specify number of ad= d-path eligible paths.

When we implement NH-SAFI draft RR will ask PE for metrics to all next hops let's say 10 it has in the BGP ta= ble. Then PE will reply with metric to 3 of them say 5, 10, 15 and metric 0= to the rest of them which means I am not interested to hear about them.
Hence RR will only send 3 paths to such PE without any need to manual = configure the number on the RR side per POP or per client.

Best rega= rds,
R.

--0-621987539-1307714554=:12659-- From bruno.decraene@orange-ftgroup.com Fri Jun 10 07:04:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8CC11E80B9 for ; Fri, 10 Jun 2011 07:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThmdJxKLvuPw for ; Fri, 10 Jun 2011 07:04:46 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5F011E81BB for ; Fri, 10 Jun 2011 07:04:45 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4D961FC417C; Fri, 10 Jun 2011 16:03:44 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 73EF3FC419B; Fri, 10 Jun 2011 15:47:02 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 15:46:44 +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_01CC2774.D5BC9CD1" Date: Fri, 10 Jun 2011 15:46:44 +0200 Message-ID: In-Reply-To: <515583.80521.qm@web37908.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwnX6oCtGC6tvagTBGTMFL38dcPBgAEMH6Q References: <515583.80521.qm@web37908.mail.mud.yahoo.com> From: To: X-OriginalArrivalTime: 10 Jun 2011 13:46:44.0973 (UTC) FILETIME=[D62AF1D0:01CC2774] Cc: gaurav.thareja@gmail.com, idr@ietf.org, raszuk@cisco.com, Chintan.Shah@colt.net, vjoseph@juniper.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:04:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2774.D5BC9CD1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Prem, =20 I agree with you that there are two needs: -a- (IGP based) shortest path routing; -b- (SP's) policy based routing. =20 And I understood your need is "b". =20 That being said, I'm not sure I understood why you state that the = combined (additional) use of RT communities & RTC is the best solutions = to fit this need. e.g. why expressing routing preference using NH SAFI is harder compared = the use of both RT communities and RTC routes. In both cases, given that = the SP wants to specify its specific need, there is a need to configure = it somewhere. (as opposed to IGP based shortest path routing where the = information is already in the IGP). e.g. why not using regular BGP communities -which I assume are already = configured on the ASBR advertising BGP routes (vs RT communities which = need to be configured additionally)- with BGP policies configured on the = RR (e.g. to refer to the example in =A75.2 of the Vinod-Lavalle draft, = only advertise route from Tokyo to PE in Tokyo). =20 Could you elaborate on this? =20 Thanks, Regards, Bruno =20 From: Reshmi Prem [mailto:reshmi_prem@yahoo.com]=20 Sent: Friday, June 10, 2011 1:15 PM To: raszuk@cisco.com Cc: vjoseph@juniper.net; DECRAENE Bruno RD-CORE-ISS; = gaurav.thareja@gmail.com; idr@ietf.org; Chintan.Shah@colt.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection =20 Robert and All, =20 I have been following this discussion and I would like add my opinions = here =20 We have been having similar requirements to steer traffic through = selective exit points in the network which are driven by customer = requirements, example having premium customers use a set of ASBRS vs. a = different set of other customers using another set of ASBRs within a = given region/POP or whatever you may like to call it. In effect, IGP = metric may not always be the the choice in our case.=20 =20 As an opertor I am interested in the best solution and the more options = we see, the better for us to choose what is appropriate for us. However = I do not see this being reflected in any of the discussions here = unfortunately.=20 =20 Back to the point, using a NH SAFI if I need three ASBR paths on a PE = (let me call this Premium PE), I do have to modify the admin costs on = each of these sets of PEs to each of the ASBR manually to a metric that = will influence the RR to announce the best path to the PE. You state = multiple paths can be announced as well - let us say I need 3. Is this = using ADD-PATH? If so how do you compute the best path on ADD-PATH? =20 On the draft using RT and RTC, I do clearly see the means of achieving a = set of preferred paths being advertised and received on the PE. The RR = in this case strictly announces paths that match a given RT list which = can also be controlled in regard to how many paths a PE is interested = in. I would imagine that in the event of a path being withdrawn, the RR = would send an alternate path with the same RT if it is available, as it = what ADD-PATH is expected to do in any case which is announce additional = paths if announced paths are withdrawn - I specifically refer to the = case where pure ADD-PATH implementations constrain the number of paths = to a specific number of paths (min and max no. of paths). =20 RT configurations are not a overhead for us, and I do not expect = everyone to feel the same. If we were to implement this solution for us, = I would just configure ASBRs with Route Targets specific to our needs, = and have the PEs choose between them. Its simple for me since even IP = addressing needs planning, VPNv4 RT allocations needed planning when we = implemented RT. I am not drawing parallels, but I am more focussed on = the ease of adding new RTs whenever a new requirement comes up. On the = topic of ensuring the best path on the PE which someone raised, I would = use a local policy to influence that. Probably use "weights" or some = equivalent or expect the authors of this draft to have a mechanism to = probably specify a method of assigning a weight to each RT, rather than = having the RR do something here. =20 I am personally not comfortable and a strong advocate against running an = SPF instance - in whatever shape on my RR. I do want any IGP related = issue, be it a software bug or any other problem in respect to the RR = having the need to have an IGP view of sorts - to impact the BGP = machine. Whatever the promises are I would want to see this perform in = my lab under different contraints using production code before this can = be looked at. =20 Summary - Nice to have two choices, a. SPF on RR for closest IGP = announcement b. Use RTs and RTC to have preference or operator based = path announcement, with the favour tilting towards the RT approach as = both the drafts in its present form stand today. =20 Prem =20 ------_=_NextPart_001_01CC2774.D5BC9CD1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Prem,

 

I agree with you that there are two = needs:

-a- (IGP based) shortest path = routing;

-b- (SP’s) policy based = routing.

 

And I understood your need is = “b”.

 

That being said, I’m not sure I understood why you = state that the combined (additional) use of RT communities & RTC is the = best solutions to fit this need.

e.g. why expressing routing preference using NH SAFI is = harder compared the use of both RT communities and RTC routes. In both cases, = given that the SP wants to specify its specific need, there is a need to configure = it somewhere. (as opposed to IGP based shortest path routing where the = information is already in the IGP).

e.g. why not using regular BGP communities -which I = assume are already configured on the ASBR advertising BGP routes (vs RT communities = which need to be configured additionally)- with BGP policies configured on the = RR (e.g. to refer to the example in =A75.2 of the Vinod-Lavalle draft, only advertise route from Tokyo to PE in Tokyo).

 

Could you elaborate on this?

 

Thanks,

Regards,

Bruno

 

From:= Reshmi = Prem [mailto:reshmi_prem@yahoo.com]
Sent: Friday, June 10, 2011 1:15 PM
To: raszuk@cisco.com
Cc: vjoseph@juniper.net; DECRAENE Bruno RD-CORE-ISS; gaurav.thareja@gmail.com; idr@ietf.org; Chintan.Shah@colt.net
Subject: Re: [Idr] = draft-vinod-lavallee-bgp-optimal-route-reflection

 

Robert and All,

 

I have been following this discussion and I would = like add my opinions here

 

We have been having similar requirements to steer = traffic through selective exit points in the network which are driven by = customer requirements, example having premium customers use a set of ASBRS vs. = a different set of other customers using another set of ASBRs within a = given region/POP or whatever you may like to call it. In effect, IGP metric = may not always be the the choice in our case.

 

As an opertor I am interested in the best = solution and the more options we see, the better for us to choose what is appropriate = for us. However I do not see this being reflected in any of the discussions = here unfortunately.

 

Back to the point, using a NH SAFI if I need = three ASBR paths on a PE (let me call this Premium PE), I do have to modify the = admin costs on each of these sets of PEs to each of the ASBR manually to a metric that will influence the RR to announce the best path to the PE. You state multiple paths can be announced as well - let = us say I need 3. Is this using ADD-PATH? If so how do you compute the best path = on ADD-PATH?

 

On the draft using RT and RTC, I do clearly see = the means of achieving a set of preferred paths being advertised and received on = the PE. The RR in this case strictly announces paths that match a given RT = list which can also be controlled in regard to how many paths a PE is = interested in. I would imagine that in the event of a path being withdrawn, the = RR would send an alternate path with the same RT if it is available, as it what ADD-PATH is expected to do in any case which is announce = additional paths if announced paths are withdrawn - I specifically refer to the = case where pure ADD-PATH implementations constrain the number of paths to a specific number of paths (min and max no. of paths).

 

RT configurations are not a overhead for us, and = I do not expect everyone to feel the same. If we were to implement this = solution for us, I would just configure ASBRs with Route Targets specific to our = needs, and have the PEs choose between them. Its simple for me since even IP addressing needs planning, VPNv4 RT allocations needed planning when = we implemented RT. I am not drawing parallels, but I am more focussed on = the ease of adding new RTs whenever a new requirement comes up. On the = topic of ensuring the best path on the PE which someone raised, I would use a = local policy to influence that. Probably use "weights" or some = equivalent or expect the authors of this draft to have a mechanism to probably = specify a method of assigning a weight to each RT, rather than having the RR do something here.

 

I am personally not comfortable and a strong = advocate against running an SPF instance - in whatever shape on my RR. I do = want any IGP related issue, be it a software bug or any other problem in = respect to the RR having the need to have an IGP view of sorts - to impact the = BGP machine. Whatever the promises are I would want to see this perform in = my lab under different contraints using production code before this can be = looked at.

 

Summary - Nice to have two choices, a. SPF on RR = for closest IGP announcement b. Use RTs and RTC to have preference or = operator based path announcement, with the favour tilting towards the RT = approach as both the drafts in its present form stand today.

 

Prem

 =

------_=_NextPart_001_01CC2774.D5BC9CD1-- From ilya@nobulus.com Fri Jun 10 07:11:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EA111E80CB for ; Fri, 10 Jun 2011 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCXhLScMMzE2 for ; Fri, 10 Jun 2011 07:11:55 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id E1F2E11E80CA for ; Fri, 10 Jun 2011 07:11:53 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 9687317177; Fri, 10 Jun 2011 16:11:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6SJDbk6HMk8x; Fri, 10 Jun 2011 16:11:47 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:7507:1c1:ad6d:e6f1]) by nobulus.com (Postfix) with ESMTPA id 721E3170CD; Fri, 10 Jun 2011 16:11:45 +0200 (CEST) Message-ID: <33B8AE7C195D466FB8E34C5A9EDC5C8C@hnivarlas1> From: "iLya" To: "Reshmi Prem" , References: <23097.50592.qm@web37903.mail.mud.yahoo.com> In-Reply-To: <23097.50592.qm@web37903.mail.mud.yahoo.com> Date: Fri, 10 Jun 2011 16:11:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:11:55 -0000 -------------------------------------------------- > I would like to understand this: > > Back to the point, using a NH SAFI if I need three ASBR paths on a PE (let > me call this Premium PE), I do have to modify the admin costs on each of > these sets of PEs to each of the ASBR manually to a metric that will > influence the RR to announce the best path to the PE. You state multiple > paths can be announced as well - let us say I need 3. Is this using > ADD-PATH? If so how do you compute the best path on ADD-PATH? > I can only guess to what such question leads, so let me show best way to implement what you desire using NH SAFI draft. PE can be configured with static sequence number of first N (3 in your case) most preferred next-hop, whatever next-hops remains after such pre-selection are ordered by ever increasing IGP cost taken _at the time of calculation_ (and and this order may change and be re-announced in the future should network topology change). This information is announced to RR via NH SAFI. The RR uses information instead of its own IGP cost to next-hop when it performs best-path selection. If ADD-PATH is not configured, RR sends only best (based on client perspective) path, if ADD-PATH is configured RR sends N (3 in your case) best (again from client perspective) path's. The beauty of this approach is that if a prefix is not available via first N (3 in your case) prefered next-hops RR will still send N (3 in your case) best (from client perspective) possible paths. Without NH SAFI and WG ORR the clients will receive best path from RR perspective (that can be on the other side of the continent) and not from their own. /iLya From raszuk@cisco.com Fri Jun 10 07:13:42 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C60411E8182 for ; Fri, 10 Jun 2011 07:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGF4+c3YGUgu for ; Fri, 10 Jun 2011 07:13:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E6C2011E80CA for ; Fri, 10 Jun 2011 07:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1173; q=dns/txt; s=iport; t=1307715220; x=1308924820; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iK6XhCecnj7gTtLLzROXxAGtHNqne11DRiwmJrgjXHM=; b=VAIwvX+tDQpFWsmJfYMhtSpkuk9daowbytuHGH1Ik8WnZ+Sj6Y4vsZVv UhasGHvcQHCWc8RduFcyZaTmpn1wEfHdzSkyM4xjmDDiiHIezRlk6SPPn OAWT4RVdVNEsgWVD7BhmPKHSumdc1efVX0wfmGBN8a5KL+LsJXLGw5DwE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJMl8k2rRDoI/2dsb2JhbABSpkV3iHKecIMODwGabYYjBJErhE6LCw X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="711594132" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 10 Jun 2011 14:13:33 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5AEDVQd005774; Fri, 10 Jun 2011 14:13:31 GMT Message-ID: <4DF22686.4090503@cisco.com> Date: Fri, 10 Jun 2011 16:13:26 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <924216.12659.qm@web37907.mail.mud.yahoo.com> In-Reply-To: <924216.12659.qm@web37907.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:13:42 -0000 > In this particular case using ORR draft RR when advertising closest exit > path, 2nd closest and 3rd closest towards PE can set local pref > accordingly to the computed order of paths so PE will select using > normal best path selection rules correctly. > > >>>>>>>>>>>How does this tie in to the whole story now? Are you saying > that in your ORR proposal I have configure manual policies on the RR for > each PE that has these needs , by statically defining each NH modifying > local-pref on the RR towards each PE? Nope .. this is automatic from the order of BGP paths selected to be advertised. No manual local pref setting on RR needed at all. > >>>>>>>> What happens if all the three NHs disappear or fail? It's normal BGP again .. you get next three available paths. Remember that metric check is just one of 14 steps of BGP best path selection. If you do not break tie at IGP metric step you move to bgp best path selection next step. And let's point out that with RT filtering in place (without this special RR RT to semantically mean always send over all best path) this is one of the problems in draft-vinod. Thx, R. From reshmi_prem@yahoo.com Fri Jun 10 03:43:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FAA21F8472 for ; Fri, 10 Jun 2011 03:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4C+owD3I5Pq for ; Fri, 10 Jun 2011 03:42:59 -0700 (PDT) Received: from nm30-vm2.bullet.mail.ne1.yahoo.com (nm30-vm2.bullet.mail.ne1.yahoo.com [98.138.91.130]) by ietfa.amsl.com (Postfix) with SMTP id CEA3C21F8470 for ; Fri, 10 Jun 2011 03:42:58 -0700 (PDT) Received: from [98.138.90.48] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 10:42:58 -0000 Received: from [98.138.89.162] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 10:42:58 -0000 Received: from [127.0.0.1] by omp1018.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 10:42:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 175919.61321.bm@omp1018.mail.ne1.yahoo.com Received: (qmail 71500 invoked by uid 60001); 10 Jun 2011 10:42:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307702577; bh=JfIfTszOdmJMGOhH0m7uw0XbkOCtoS/up8Cluan0T9E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=O4+sD6/are8L6EJ9brXBsZHpah6bVuzRDSMkQIsdmddsnTWvC+4KWskYmA8iXq3MhHvQkk1/G2xiIElFVJE/mI809pEpwykBHtaY/V0ehMGSNSS8nqfqPp4Mp6jlg2Fn8W/c7f2o42+sLAl/9ou2QhfSokYuoavCgPzWo5tRBp4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=F3olHO607B4wi4ho0klpy+L7nHrumOaZohkcCABLA8vcV9afBimDiEiWoh2pCWX8uB/j9iAQ3D8e9ILnNE1RVutdXdreEXcSlQOAokzK7v/Ld1SkoQXcthSvstlhwwS5LzPK6nBbi9y4C6U/KNDI6ADoiJUthrLMTiKtK8maSKM=; Message-ID: <717474.30883.qm@web37908.mail.mud.yahoo.com> X-YMail-OSG: bIZNprIVM1k5x7YTzmcAwgxiAHKibtPm280eULQU.Gdvtjo j1RVQLcYnpDNsiUXtaG.c2AxCpQj0xiWAu.yftbZu5qkiRUy0I35.QGNgwFn c95ABEAdpSJjPSSVWoOO2tLA9bP2.YAbNZJ5QLkDgYJaNaUEuvHDwiXnNzJZ vMPh28BhoarO48sxKXzll0ESwUDqF96GH7v5gT7iXVhFwUnX4eWtHStfAaLO 04r_wS00ZeDVMymBZz9e90WFUEPn8.FEjBxeCNExZe4ukPYPrx77phRdhCMl jELHPK9XPlP5ymGHq2.wQtDWNdySmXfGGnb_BAwK2z5eEksGXxTHImsBymx8 ll8iSBzTilvlMoF8SA7S0Dl0zunlt4Om03_Rusi6qN0xGuVsrW0a4LdTgPBA goU4oFuOfDZaUJQ-- Received: from [66.129.224.36] by web37908.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 03:42:57 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 03:42:57 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1903164655-1307702577=:30883" X-Mailman-Approved-At: Fri, 10 Jun 2011 07:23:18 -0700 Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:07:59 -0000 --0-1903164655-1307702577=:30883 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Robert and All, =A0 I have been following this discussion and I would like add my opinions here =A0 We have been having similar requirements to steer traffic through selective= exit points in the network which are driven by customer requirements, exam= ple having premium customers use a set of ASBRS vs. a different set of othe= r customers using another set of ASBRs within a given region/POP or whateve= r you may like to call it. In effect, IGP metric may not always be the the = choice in=A0our case.=20 =A0 As an opertor I am interested in the best solution and the more options we = see, the better for us to choose what is appropriate for us. However I do n= ot see this being reflected in any of the discussions here unfortunately.= =20 =A0 Back to the point, using a NH SAFI if I need three ASBR paths on a PE (let = me call this Premium PE), I do have to modify the admin costs on each of th= ese sets of PEs to each of the ASBR manually to a metric=A0that will influe= nce the RR to announce the best path to the=A0PE. You state multiple paths = can be announced as well - let us say I need 3. Is this using ADD-PATH? If = so how do you compute the best path on ADD-PATH? =A0 On the draft using RT and RTC, I do clearly see the means of achieving a se= t of preferred paths being advertised and received on the PE. The RR in thi= s case strictly announces paths that match a given RT list which can also b= e controlled in regard to how many paths a PE is interested in. I would ima= gine that in the event of a path being withdrawn, the RR would send an alte= rnate path with the same RT if it is available, as it what ADD-PATH is expe= cted to do=A0in any case which is announce additional paths if announced pa= ths are withdrawn - I specifically refer to the case where pure ADD-PATH im= plementations constrain the number of paths to a specific number of paths (= min and max no. of paths). =A0 RT configurations are not a overhead for us, and I do not expect everyone t= o feel the same. If we were to implement this solution for us, I would just= configure ASBRs with Route Targets specific to our needs, and have the PEs= choose between them. Its simple for me since even IP addressing needs plan= ning, VPNv4 RT allocations needed planning when we implemented RT. I am not= drawing parallels, but I am more focussed on the ease of adding new RTs wh= enever a new requirement comes up. On the topic of ensuring the best path o= n the PE which someone raised, I would use a local policy to influence that= . Probably use "weights" or some equivalent or expect the authors of this d= raft to have a mechanism to probably specify a method of assigning a weight= to each RT, rather than having the RR do something here. =A0 I am personally not comfortable and a strong advocate against running an SP= F instance - in whatever shape on my RR. I do want any IGP related issue, b= e it a software bug or any other problem in respect to the RR having the ne= ed to have an IGP view of sorts - to impact the BGP machine. Whatever the p= romises are I would want to see this perform in my lab under different cont= raints using production code before this can be looked at. =A0 Summary - Nice to have two choices, a. SPF on RR for closest IGP announceme= nt b. Use RTs and RTC to have preference or operator based path announcemen= t, with the favour tilting towards the RT approach as both the drafts in it= s present form stand today. =A0 Prem --0-1903164655-1307702577=:30883 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Robert and All,
 
I have been following this discussion and I would like add my opinions= here
 
We have been having similar requirements to steer traffic through sele= ctive exit points in the network which are driven by customer requirements,= example having premium customers use a set of ASBRS vs. a different set of= other customers using another set of ASBRs within a given region/POP or wh= atever you may like to call it. In effect, IGP metric may not always be the= the choice in our case.
 
As an opertor I am interested in the best solution and the more option= s we see, the better for us to choose what is appropriate for us. However I= do not see this being reflected in any of the discussions here unfortunate= ly.
 
Back to the point, using a NH SAFI if I need three ASBR paths on a PE = (let me call this Premium PE), I do have to modify the admin costs on each = of these sets of PEs to each of the ASBR manually to a metric that wil= l influence the RR to announce the best path to the PE. You state mult= iple paths can be announced as well - let us say I need 3. Is this using AD= D-PATH? If so how do you compute the best path on ADD-PATH?
 
On the draft using RT and RTC, I do clearly see the means of achieving= a set of preferred paths being advertised and received on the PE. The RR i= n this case strictly announces paths that match a given RT list which can a= lso be controlled in regard to how many paths a PE is interested in. I woul= d imagine that in the event of a path being withdrawn, the RR would send an= alternate path with the same RT if it is available, as it what ADD-PATH is= expected to do in any case which is announce additional paths if anno= unced paths are withdrawn - I specifically refer to the case where pure ADD= -PATH implementations constrain the number of paths to a specific number of= paths (min and max no. of paths).
 
RT configurations are not a overhead for us, and I do not expect every= one to feel the same. If we were to implement this solution for us, I would= just configure ASBRs with Route Targets specific to our needs, and have th= e PEs choose between them. Its simple for me since even IP addressing needs= planning, VPNv4 RT allocations needed planning when we implemented RT. I a= m not drawing parallels, but I am more focussed on the ease of adding new R= Ts whenever a new requirement comes up. On the topic of ensuring the best p= ath on the PE which someone raised, I would use a local policy to influence= that. Probably use "weights" or some equivalent or expect the authors of t= his draft to have a mechanism to probably specify a method of assigning a w= eight to each RT, rather than having the RR do something here.
 
I am personally not comfortable and a strong advocate against running = an SPF instance - in whatever shape on my RR. I do want any IGP related iss= ue, be it a software bug or any other problem in respect to the RR having t= he need to have an IGP view of sorts - to impact the BGP machine. Whatever = the promises are I would want to see this perform in my lab under different= contraints using production code before this can be looked at.
 
Summary - Nice to have two choices, a. SPF on RR for closest IGP annou= ncement b. Use RTs and RTC to have preference or operator based path announ= cement, with the favour tilting towards the RT approach as both the drafts = in its present form stand today.
 
Prem
--0-1903164655-1307702577=:30883-- From reshmi_prem@yahoo.com Fri Jun 10 07:30:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBB611E818A for ; Fri, 10 Jun 2011 07:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gfzhBWuu+ne for ; Fri, 10 Jun 2011 07:30:32 -0700 (PDT) Received: from nm18-vm0.bullet.mail.ac4.yahoo.com (nm18-vm0.bullet.mail.ac4.yahoo.com [98.139.53.210]) by ietfa.amsl.com (Postfix) with SMTP id 1B6C81F0C66 for ; Fri, 10 Jun 2011 07:30:32 -0700 (PDT) Received: from [98.139.52.188] by nm18.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 14:30:28 -0000 Received: from [98.139.52.145] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 14:30:28 -0000 Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 10 Jun 2011 14:30:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 503526.30183.bm@omp1028.mail.ac4.yahoo.com Received: (qmail 10962 invoked by uid 60001); 10 Jun 2011 14:30:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307716226; bh=0XDixaQ/iN3DQH1jdV8heo+TKsGJ+YQsKDppjhF0pzY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2gLlSx3StJQzEdLspaHGYqzfzitjY6A1vUeNgfQOceRR2fveEGFRQL0zVpkqHyS9GjFjIIYKtgZ6fG671km39uE3BG0MpE2uoffCCFPuJKXRW0up2V4fkb/yxG344AlArZQ60oynmBpcBftROPlFKTMwAurty9lA69QqzOJRsRA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aOfqGBY25vqE365qmjFm97GeVgxn52i9lImyHrttChp0VJcBtgOg2j0YcAsUODn7ggCHl8T2Xv+JmCTRL1XsAvy7pGIpjsNp3R30xWPwcMVxjd4pNTUjf2L2eQET2C3UujnvZhs9SGjJDHsshRk1yP/a3nRRaHtbhiOPaBQb95M=; Message-ID: <924687.99284.qm@web37906.mail.mud.yahoo.com> X-YMail-OSG: k6y7FO4VM1maAs85Y5pAQB8P1Xv4dWLwLsTDEgE4q4UfAmn SbmqZfZY7IbVLqxyQgCSESDDrUBUyc7uOiGXVpB_cpCTrtN2hlSlxbFjYGFt .yoMRN.84eDCfj8iOPU_QHB5FD8M.4RZelqyD_R0mfvF3etfwIa3Y3jVU8BD uAUP6eFmI_MpkdV7eyj1WYh8qit9n8roZGPm6htk1x0DfjovB7Vv7uYQPc2c pYfB9IE5g1iaYGFfpy40p3Ab8ak_ibOptVSWuAiUuBNrdQFriKKXYGxNc.u9 s2AHDOyK_Mj6zizIoE_5h4dSfmbgRdFYx98D.3Dgy38EcHWu9zTE0Ku8Rn3u C.YqjPB1zrE5cg8lAg66U2dC4H3qdvUbYDwbRes_WWrIMGMnXpBTkVZpyxYO geA88Iw13BsLU Received: from [66.129.224.36] by web37906.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 07:30:26 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 07:30:26 -0700 (PDT) From: Reshmi Prem To: raszuk@cisco.com In-Reply-To: <4DF22686.4090503@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2102035447-1307716226=:99284" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:30:33 -0000 --0-2102035447-1307716226=:99284 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All, =A0 With Robert's ORR Draft =3D Manual configurations needed on the RR to list = an order of BGP paths to be advertised per PE (I use the term per PE to mak= e it granular). If they disappear, then next 3 paths as per RRs business as= usual (RRs independent decission). Each time a new ASBR is added and has t= o be used by this PE, Policy on the RR needs to be modified. Concern: Our n= etwork tries to minimize or have no manual configurations on RRs. With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a Rout= e Target assignment. Multiple paths can be announced as per RTC. Would be k= een to understand how the local PE would handle best path selection - Local= weights per RT, Local policy on PE??.=20 =A0 NH Draft: No policy on RR, only PEs need to be manually configured with adm= in costs and RR does reflect best paths based on these values. Concern: Wit= h vinod's draft, an RT can mean more than a single ASBR, but with NH draft,= each ASBR path needed in the PE needs to be configured with an Admin cost,= so more work. Add-path used for announcing multiple paths (illiya mentione= d it).=20 =A0 Both NH and Vinod's ORR draft still specify that in the event of an ASBR pa= th being withdrawn, an additional path will be advertised since this is the= default behavior of ADD-PATH - So Vinod's draft and NH draft are not doing= something novel from what Add-Path specifies. =A0 Prem --- On Fri, 6/10/11, Robert Raszuk wrote: From: Robert Raszuk Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: vjoseph@juniper.net, bruno.decraene@orange-ftgroup.com, gaurav.thareja@= gmail.com, idr@ietf.org, Chintan.Shah@colt.net Date: Friday, June 10, 2011, 9:13 AM > In this particular case using ORR draft RR when advertising closest exit > path, 2nd closest and 3rd closest towards PE can set local pref > accordingly to the computed order of paths so PE will select using > normal best path selection rules correctly. >=20 >=A0 >>>>>>>>>>>How does this tie in to the whole story now? Are you saying > that in your ORR proposal I have configure manual policies on the RR for > each PE that has these needs , by statically defining each NH modifying > local-pref on the RR towards each PE? Nope .. this is automatic from the order of BGP paths selected to be advert= ised. No manual local pref setting on RR needed at all. >=A0 >>>>>>>> What happens if all the three NHs disappear or fail? It's normal BGP again .. you get next three available paths. Remember that = metric check is just one of 14 steps of BGP best path selection. If you do not break tie at IGP metric step you move to bgp best path select= ion next step. And let's point out that with RT filtering in place (without this special R= R RT to semantically mean always send over all best path) this is one of th= e problems in draft-vinod. Thx, R. --0-2102035447-1307716226=:99284 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,
 
With Robert's ORR Draft =3D Manual configurations needed on the RR to = list an order of BGP paths to be advertised per PE (I use the term per PE t= o make it granular). If they disappear, then next 3 paths as per RRs busine= ss as usual (RRs independent decission). Each time a new ASBR is added and = has to be used by this PE, Policy on the RR needs to be modified. Concern: = Our network tries to minimize or have no manual configurations on RRs.
<= /DIV>
With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a= Route Target assignment. Multiple paths can be announced as per RTC. Would= be keen to understand how the local PE would handle best path selection - = Local weights per RT, Local policy on PE??.
 
NH Draft: No policy on RR, only PEs need to be manually configured wit= h admin costs and RR does reflect best paths based on these values. Concern= : With vinod's draft, an RT can mean more than a single ASBR, but with NH d= raft, each ASBR path needed in the PE needs to be configured with an Admin = cost, so more work. Add-path used for announcing multiple paths (illiya men= tioned it).
 
Both NH and Vinod's ORR draft still specify that in the event of an AS= BR path being withdrawn, an additional path will be advertised since this i= s the default behavior of ADD-PATH - So Vinod's draft and NH draft are not = doing something novel from what Add-Path specifies.
 
Prem
--- On Fri, 6/10/11, Robert Raszuk <raszuk@cisco.com&= gt; wrote:

From: Robert Raszuk <raszuk@cisco.com>
S= ubject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To: = "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: vjoseph@juniper.net, bru= no.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, idr@ietf.org, Chi= ntan.Shah@colt.net
Date: Friday, June 10, 2011, 9:13 AM


> In this particular case using ORR draft RR = when advertising closest exit
> path, 2nd closest and 3rd closest tow= ards PE can set local pref
> accordingly to the computed order of pat= hs so PE will select using
> normal best path selection rules correct= ly.
>
>  >>>>>>>>>>>How = does this tie in to the whole story now? Are you saying
> that in you= r ORR proposal I have configure manual policies on the RR for
> each = PE that has these needs , by statically defining each NH modifying
> = local-pref on the RR towards each PE?

Nope .. this is automatic from= the order of BGP paths selected to be advertised. No manual local pref set= ting on RR needed at all.

>  >>>>>>>>= ; What happens if all the three NHs disappear or fail?

It's normal B= GP again .. you get next three available paths. Remember that metric check is just one of 14 steps of BGP best path selection.

If you do= not break tie at IGP metric step you move to bgp best path selection next = step.

And let's point out that with RT filtering in place (without t= his special RR RT to semantically mean always send over all best path) this= is one of the problems in draft-vinod.

Thx,
R.

--0-2102035447-1307716226=:99284-- From jgs@juniper.net Fri Jun 10 07:32:21 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9D11E81B6 for ; Fri, 10 Jun 2011 07:32:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46iCJvUvTCpA for ; Fri, 10 Jun 2011 07:32:20 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 94FD611E81A9 for ; Fri, 10 Jun 2011 07:32:20 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTfIq85kzRGFw+IOacVZFIev/8g1lUk7U@postini.com; Fri, 10 Jun 2011 07:32:20 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 10 Jun 2011 07:30:03 -0700 From: John Scudder To: "idr@ietf.org List" Date: Fri, 10 Jun 2011 07:30:02 -0700 Thread-Topic: [Idr] WGLC for draft-ietf-idr-fsm-subcode-01 Thread-Index: AcwneuMB8GmTO4uwSrmAXgA2jf6OHg== Message-ID: <5B40A04C-9415-44E4-B26E-560DCDF2AF94@juniper.net> References: In-Reply-To: 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 Subject: Re: [Idr] WGLC for draft-ietf-idr-fsm-subcode-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:32:21 -0000 Folks, There was minimal response to this (just one person who said "it's ready, p= ublish it"). If there are any further comments please send them by June 17= , otherwise we will consider the WGLC to have completed and will proceed wi= th the next steps to advance the document. Thanks, --John On Apr 12, 2011, at 10:57 PM, John Scudder wrote: > Folks, >=20 > This is to start an IDR working group last call for draft-ietf-idr-fsm-su= bcode-01. Please send your comments by April 27. >=20 > Thanks, >=20 > --John From ilya@nobulus.com Fri Jun 10 09:17:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C181411E8090 for ; Fri, 10 Jun 2011 09:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJWbxnhr35rq for ; Fri, 10 Jun 2011 09:17:55 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id D765811E8093 for ; Fri, 10 Jun 2011 09:17:49 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id E558C1746B; Fri, 10 Jun 2011 18:17:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aQm5fNC+1B3G; Fri, 10 Jun 2011 18:17:44 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:7507:1c1:ad6d:e6f1]) by nobulus.com (Postfix) with ESMTPA id CFEB51744F; Fri, 10 Jun 2011 18:17:44 +0200 (CEST) Message-ID: <7F84B2FDB6554F3F8203DB64E626AB72@hnivarlas1> From: "iLya" To: "Reshmi Prem" , References: <924687.99284.qm@web37906.mail.mud.yahoo.com> In-Reply-To: <924687.99284.qm@web37906.mail.mud.yahoo.com> Date: Fri, 10 Jun 2011 18:17:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 16:17:55 -0000 -------------------------------------------------- > With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a > Route Target assignment. Multiple paths can be announced as per RTC. Would > be keen to understand how the local PE would handle best path selection - > Local weights per RT, Local policy on PE??. > if there are multiple non-preferred next-hops (which are not available via preferred), then Vinod's draft would return routes based on RR's view of the world > NH Draft: No policy on RR, only PEs need to be manually configured with > admin costs and RR does reflect best paths based on these values. Concern: > With vinod's draft, an RT can mean more than a single ASBR, but with NH > draft, each ASBR path needed in the PE needs to be configured with an > Admin cost, so more work. Add-path used for announcing multiple paths > (illiya mentioned it). > Note that with NH draft you indeed configure N preferences on each of K PE, but nothing on ASBRs, so in total O(N*K)complexity. With RT you configure 1 RT (assuming that RT-default is always wanted by default) on each of K PE and M RT on each L ASBR, so in total O(K+M*L) complexity. If you want two preferred exits for 100 PE (PE's don't have to have same preferences) then 200 steps in case of NH draft regardless of number of ASBR's. If you have 100 PE's and 50 ASBR's then you have 150 steps in case of Vinod's draft. I think 200 (NH) vs 150 (Vinod) steps is price worth paying for getting best route (in case of NH draft) from client's perspective in case destination prefix is not available over preferred path. Should you think the numbers in my example are low, I'd be interested to see realistic scenario where numbers will be significantly higher. > Both NH and Vinod's ORR draft still specify that in the event of an ASBR > path being withdrawn, an additional path will be advertised since this is > the default behavior of ADD-PATH - So Vinod's draft and NH draft are not > doing something novel from what Add-Path specifies. > the difference is in this case NH SAFI draft will provide best route from client's perspective, Vinod's draft will provide best route from RR perspective. Kind regards, iLya From vjoseph@juniper.net Fri Jun 10 10:15:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8815D11E812B for ; Fri, 10 Jun 2011 10:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBW3fkSqZJZi for ; Fri, 10 Jun 2011 10:15:54 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id CAB9811E80A2 for ; Fri, 10 Jun 2011 10:15:43 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTfJRP+RmYimZ2IaLtDY70RChaknmibiK@postini.com; Fri, 10 Jun 2011 10:15:54 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Fri, 10 Jun 2011 10:13:03 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 18:13:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jun 2011 18:12:56 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FD9A@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwnifMrqUm/arTBSSav0dlqH0YAoQABRZ9Q References: <924687.99284.qm@web37906.mail.mud.yahoo.com> <7F84B2FDB6554F3F8203DB64E626AB72@hnivarlas1> From: Vinod Joseph To: iLya , Reshmi Prem , X-OriginalArrivalTime: 10 Jun 2011 17:13:01.0240 (UTC) FILETIME=[A6FF6B80:01CC2791] Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:15:55 -0000 Ilya and Prem, if there are multiple non-preferred next-hops (which are not available = via=20 preferred), then Vinod's draft would return routes based on RR's view of = the=20 world Vinod - As with the NH draft where you need to define admin metrics on a = per ASBR, with the proposed draft you would need to identify potential = ASBRs in the network which you want to signal interest in.=20 the difference is in this case NH SAFI draft will provide best route = from=20 client's perspective, Vinod's draft will provide best route from RR=20 perspective. Vinod - That's not correct, If a path belonging to an RT is withdrawn = then the RR would announce another path ASBR path that matches the same = RT.=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: iLya [mailto:ilya@nobulus.com]=20 Sent: 10 June 2011 17:18 To: Reshmi Prem; raszuk@cisco.com Cc: gaurav.thareja@gmail.com; bruno.decraene@orange-ftgroup.com; = Chintan.Shah@colt.net; Vinod Joseph; idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection -------------------------------------------------- > With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a = > Route Target assignment. Multiple paths can be announced as per RTC. = Would=20 > be keen to understand how the local PE would handle best path = selection -=20 > Local weights per RT, Local policy on PE??. > if there are multiple non-preferred next-hops (which are not available = via=20 preferred), then Vinod's draft would return routes based on RR's view of = the=20 world > NH Draft: No policy on RR, only PEs need to be manually configured = with=20 > admin costs and RR does reflect best paths based on these values. = Concern:=20 > With vinod's draft, an RT can mean more than a single ASBR, but with = NH=20 > draft, each ASBR path needed in the PE needs to be configured with an=20 > Admin cost, so more work. Add-path used for announcing multiple paths=20 > (illiya mentioned it). > Note that with NH draft you indeed configure N preferences on each of K = PE,=20 but nothing on ASBRs, so in total O(N*K)complexity. With RT you = configure 1=20 RT (assuming that RT-default is always wanted by default) on each of K = PE=20 and M RT on each L ASBR, so in total O(K+M*L) complexity. If you want = two=20 preferred exits for 100 PE (PE's don't have to have same preferences) = then=20 200 steps in case of NH draft regardless of number of ASBR's. If you = have=20 100 PE's and 50 ASBR's then you have 150 steps in case of Vinod's draft. = I=20 think 200 (NH) vs 150 (Vinod) steps is price worth paying for getting = best=20 route (in case of NH draft) from client's perspective in case = destination=20 prefix is not available over preferred path. Should you think the = numbers in=20 my example are low, I'd be interested to see realistic scenario where=20 numbers will be significantly higher. > Both NH and Vinod's ORR draft still specify that in the event of an = ASBR=20 > path being withdrawn, an additional path will be advertised since this = is=20 > the default behavior of ADD-PATH - So Vinod's draft and NH draft are = not=20 > doing something novel from what Add-Path specifies. > the difference is in this case NH SAFI draft will provide best route = from=20 client's perspective, Vinod's draft will provide best route from RR=20 perspective. Kind regards, iLya =20 From reshmi_prem@yahoo.com Fri Jun 10 10:21:14 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8821F8490 for ; Fri, 10 Jun 2011 10:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bcjaflj+Nq1p for ; Fri, 10 Jun 2011 10:21:11 -0700 (PDT) Received: from nm10-vm3.bullet.mail.ne1.yahoo.com (nm10-vm3.bullet.mail.ne1.yahoo.com [98.138.91.140]) by ietfa.amsl.com (Postfix) with SMTP id 399BA21F848F for ; Fri, 10 Jun 2011 10:21:11 -0700 (PDT) Received: from [98.138.90.48] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 17:21:10 -0000 Received: from [98.138.89.171] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 17:21:10 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 17:21:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 311629.59360.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 46507 invoked by uid 60001); 10 Jun 2011 17:21:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307726469; bh=xoIxo3e+k/ADUezkmyBdMbU7QGilUf7KAE7IoOvXGZA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0xU9dn4l/5uvZyndQAP8J2pAM6ps0/hW6ay9tZQSCGqDDmiV6/FTcxGtEUVQYw6sRa+CEw6YLvo5czBwkOSQZvbCrevcaQ8zi+IDjm2ggVhmj33rNJCxlAHJrUrE1KB2ekH6uwuf6Xm+S5OEJoct1ooyREIfNKXVnsE+1hkYT9g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=V7GLjMeAqNwpPL9w5B/NRal8gH1oTNvz2MUZeRw23RNURjAFOHwgYOfOUGcIY9KoL4/7tozIbpM6MRuno7MGqWKgZ+pymB9zb+EVO3FOlnREqj6Od2hCXB9cboiMOWZ4y3qXi+8G9cW/zSQlIHRgGhyw3kiAFihm3jEwOl/cog0=; Message-ID: <663183.34305.qm@web37907.mail.mud.yahoo.com> X-YMail-OSG: kb8NpU8VM1lCDUnhqkYrjD7PysqNLPhmSkiHgEKPhPAq560 6FVfVZ83FnDDq795_P4bb7sr3fKEqkxsi2xlQ88HnBiOMlefJAD5n_5Yk689 vhzzr.y8Q3peRc_z9jHfkmuN.YW9usgHQtf.wdPqUS8kMvTIbdoxthU9HxEm QRIxbRKX2SGrT55vfzO24F3mr6SVmRJ.sVbsxZv58YcrXugaiRjh6Dstj5h0 OhaYLEKAwQio3gbGAEPhdy27ERcWAzmX1B7ZUb.9GWdmZS_Y3_Ly0yd8bBtd D1A0MKVHn08YtFlsAI6H7YMkRV0UwFuEfdrDQY9mVtG52HIx9u5xOZtvCBGQ H9hf6yA6f5w5aD0xZJEyWug3lv7Iil3aXa0tzxEIRy2NCaTmfaVp9xuUTQD_ WO_xJseDkkcf1sQerPGwRb441E0ByUfjnpFI6MaCRj95i8AGSesLjw0T6UxI l92_uYVbjE6BrwGn66LlEk.owspfDjZnsXMZRA6DzSLsZA2Q_2pJ.KlhptNn k7j_zUFjKVl0- Received: from [66.129.224.36] by web37907.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 10:21:09 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 10:21:09 -0700 (PDT) From: Reshmi Prem To: iLya , raszuk@cisco.com, Vinod Joseph In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FD9A@emailemea4.jnpr.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1283907360-1307726469=:34305" Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:21:14 -0000 --0-1283907360-1307726469=:34305 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ilya, =A0 I did not see your draft specifying that you would be using ADD-PATH, Can y= ou confirm this? =A0 Vinod's draft specifies a means of using an RR specific RT to permit a RR c= alculated best path in addition to RTC specified paths. How does your draft= handle this? What happens if the list of ASBRS that i indicate a metric fo= r disappear?? =A0 Prem --- On Fri, 6/10/11, Vinod Joseph wrote: From: Vinod Joseph Subject: RE: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "iLya" , "Reshmi Prem" , raszu= k@cisco.com Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Sh= ah@colt.net, idr@ietf.org Date: Friday, June 10, 2011, 12:12 PM Ilya and Prem, if there are multiple non-preferred next-hops (which are not available via= =20 preferred), then Vinod's draft would return routes based on RR's view of th= e=20 world Vinod - As with the NH draft where you need to define admin metrics on a pe= r ASBR, with the proposed draft you would need to identify potential ASBRs = in the network which you want to signal interest in.=20 the difference is in this case NH SAFI draft will provide best route from= =20 client's perspective, Vinod's draft will provide best route from RR=20 perspective. Vinod - That's not correct, If a path belonging to an RT is withdrawn=A0 th= en the RR would announce another path ASBR path that matches the same RT.= =20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: iLya [mailto:ilya@nobulus.com]=20 Sent: 10 June 2011 17:18 To: Reshmi Prem; raszuk@cisco.com Cc: gaurav.thareja@gmail.com; bruno.decraene@orange-ftgroup.com; Chintan.Sh= ah@colt.net; Vinod Joseph; idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection -------------------------------------------------- > With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a=20 > Route Target assignment. Multiple paths can be announced as per RTC. Woul= d=20 > be keen to understand how the local PE would handle best path selection -= =20 > Local weights per RT, Local policy on PE??. > if there are multiple non-preferred next-hops (which are not available via= =20 preferred), then Vinod's draft would return routes based on RR's view of th= e=20 world > NH Draft: No policy on RR, only PEs need to be manually configured with= =20 > admin costs and RR does reflect best paths based on these values. Concern= :=20 > With vinod's draft, an RT can mean more than a single ASBR, but with NH= =20 > draft, each ASBR path needed in the PE needs to be configured with an=20 > Admin cost, so more work. Add-path used for announcing multiple paths=20 > (illiya mentioned it). > Note that with NH draft you indeed configure N preferences on each of K PE,= =20 but nothing on ASBRs, so in total O(N*K)complexity. With RT you configure 1= =20 RT (assuming that RT-default is always wanted by default) on each of K PE= =20 and M RT on each L ASBR, so in total O(K+M*L) complexity. If you want two= =20 preferred exits for 100 PE (PE's don't have to have same preferences) then= =20 200 steps in case of NH draft regardless of number of ASBR's. If you have= =20 100 PE's and 50 ASBR's then you have 150 steps in case of Vinod's draft. I= =20 think 200 (NH) vs 150 (Vinod) steps is price worth paying for getting best= =20 route (in case of NH draft) from client's perspective in case destination= =20 prefix is not available over preferred path. Should you think the numbers i= n=20 my example are low, I'd be interested to see realistic scenario where=20 numbers will be significantly higher. > Both NH and Vinod's ORR draft still specify that in the event of an ASBR= =20 > path being withdrawn, an additional path will be advertised since this is= =20 > the default behavior of ADD-PATH - So Vinod's draft and NH draft are not= =20 > doing something novel from what Add-Path specifies. > the difference is in this case NH SAFI draft will provide best route from= =20 client's perspective, Vinod's draft will provide best route from RR=20 perspective. Kind regards, iLya --0-1283907360-1307726469=:34305 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --0-1283907360-1307726469=:34305-- From ilya@nobulus.com Fri Jun 10 12:04:12 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319FE11E8075 for ; Fri, 10 Jun 2011 12:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXf31ZBmg24D for ; Fri, 10 Jun 2011 12:04:11 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id C708F11E8122 for ; Fri, 10 Jun 2011 12:04:10 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id C28A71744E; Fri, 10 Jun 2011 21:04:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7EmHq+hzPQEt; Fri, 10 Jun 2011 21:04:05 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id CF9F9170CD; Fri, 10 Jun 2011 21:04:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <663183.34305.qm@web37907.mail.mud.yahoo.com> Date: Fri, 10 Jun 2011 21:04:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37AF49F2-28AA-4858-83CA-E25380DC94E9@nobulus.com> References: <663183.34305.qm@web37907.mail.mud.yahoo.com> To: Reshmi Prem X-Mailer: Apple Mail (2.1084) Cc: IETF IDR , bruno.decraene@orange-ftgroup.com, Vinod Joseph , "raszuk@cisco.com Raszuk" , gaurav.thareja@gmail.com, Chintan.Shah@colt.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 19:04:12 -0000 On Jun 10, 2011, at 19:21 , Reshmi Prem wrote: > Ilya, > =20 > I did not see your draft specifying that you would be using ADD-PATH, = Can you confirm this? >=20 ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As = long as you don't do anything what other specification forbids, do you = need to describe every possible combination of features that could be = used together? Today you can use ADD-PATH to send multiple PATHs, = tomorrow there will be another solution to do it. NH SAFI neither = forbids nor requires you to use any other BGP feature beyond what's = specified in the drafts, so by all means if you want multiple best PATHs = from RR-client perspective you can combine NH SAFI with ADD-PATH. If you = don't need multiple paths, you just don't use multiple paths. Do you = feel this combination should be explicitly spelled in the NH SAFI specs? > Vinod's draft specifies a means of using an RR specific RT to permit a = RR calculated best path in addition to RTC specified paths. How does = your draft handle this? What happens if the list of ASBRS that i = indicate a metric for disappear?? ok, implicit assumption is that RR will use a) cost provided by RR-c; b) = if RR-c cost is unavailable for whatever reason RR will use its own = cost. Note that original idea is that RR-c informs RR about all costs. = If network policies call for non-IGP preference, then RR-c can use = ever-increasing numbers calculated in a way operator prefers. First N = (number of preferred exits) can be explicitly configured on RR-c, the = rest RR-c will calculate itself by ordering IGP costs of remaining = exits. To give an example: a PE prefers NH5 and NH9, which operator = configures on the PE manually. Let's say at some moment _all_ prefixes = are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following = info to RR: first it tells that NH5:cost1, NH9:cost2 (because it = configured by operator), then PE takes remaining next-hops and arranges = them in order of increasing IGP cost behind first two next-hops, the = cost reported for NH-i to RR is the position of that NH-i in the just = created list. When IGP cost to non-preferred next-hops changes (due to = topology change), PE just re-evaluates NH order and sends updated cost = to RR. When preferred ASBR's are not available as feasible path to = certain prefix, RR just uses whatever is next NH in the list received = from RR-c but only for prefixes where preferred ASBR is not feasible = exit. When preferred ASBR's fail (i.e. no path can be reached via them), = RR uses for whatever is next NH in the list received from RR-c for all = prefixes. So in general, when certain prefix cannot be reached via = preferred ASBR's (regardless of the reason) then RR uses next NH in the = list received from RR-c. If for some reason connectivity from RR-c to = ASBR fails, RR-c will inform RR that particular NH is no longer feasible = (as described in NH SAFI draft) and RR will stop considering that ASBR = when calculating routes for given RR-c (even if from RR perspective or = from any other router perspective that very same ASBR is still = reachable). Same question as above - do you feel such behaviour should = be explicitly spelled out even though it's natural? Kind regards, iLya From reshmi_prem@yahoo.com Fri Jun 10 12:39:18 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7B11E814E for ; Fri, 10 Jun 2011 12:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7tbegAk2AfO for ; Fri, 10 Jun 2011 12:39:17 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ne1.yahoo.com (nm3-vm0.bullet.mail.ne1.yahoo.com [98.138.91.55]) by ietfa.amsl.com (Postfix) with SMTP id 4FF8B11E814D for ; Fri, 10 Jun 2011 12:39:17 -0700 (PDT) Received: from [98.138.90.54] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 19:39:16 -0000 Received: from [98.138.89.160] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 19:39:16 -0000 Received: from [127.0.0.1] by omp1016.mail.ne1.yahoo.com with NNFMP; 10 Jun 2011 19:39:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 857461.83966.bm@omp1016.mail.ne1.yahoo.com Received: (qmail 49650 invoked by uid 60001); 10 Jun 2011 19:39:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307734746; bh=qt5J/l0EFi4BZNubHlii5gERWRSJ+HDddbztVgsTF5w=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QexLiBkLjYT9qibD6pWarNKmTEfU5D3u++optHC+NL/f2uq8gRBioxvV7punxaXStlXLNOK0oaFo/BqjlmkvNAz7JI8fmHOiOWWgP1ed4n50+6nhNJ2kT8VPe/2NpTdRE7+ZcDLaujvhUdTyTuJuoEgi9uF2G6kwkrdaMb6szO8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hJXMSEDBYhUtAbdyNy3/HxQyui4AHhAEV0veAjShh0nsrss0c+5YZOM/5ypqSuhqodUyr4LdseAulsAQYgfmy59xsUvtsJHnuLyl5/0PPwwkx+HxHmMCGFHqfLNz2fWKyj/HeiiolDdl/DUlv3Iw+Hd+mTQ0bkRo2KslZleQbdI=; Message-ID: <243870.49492.qm@web37903.mail.mud.yahoo.com> X-YMail-OSG: BtAEFZkVM1lEh94dyALRkUTgMRXjL3wRSR56KjG0lV9So.b 7tLdDZDttG0J22R8xnBfzox15vgsFp1kHvf6SgPNzTGUP0rJ5rpw0PGxrf19 u_xg1ntV60afPyEwwQBzrxDmXo1kPtccfNx9a6s1jP0OuthlSIG4WRH5gPLG VchAA1Yxu8W_J9HRugySAFDBoTbzsVDd6OzLWeCywmY2cEuAa.Hm6C4ZeTJv dUY5aZYKQuEVIgPfjRSHlqKJYqBYxfE04HYu.zag14lNaheU5gMl2REj5Mvk HK607plQ6K9n7N9OrevYAEZNvE8tYZt.sqmMD9QW8L_WzbF7GNAyHdzcvj1Q OaM85In0rY3YdXcm17jiZDA3Dmw3yIzYC2gZJhfmPp5Kxffn_F4ljiie.pgz syGWZWGBqsxZz Received: from [66.129.224.36] by web37903.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 12:39:06 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 12:39:06 -0700 (PDT) From: Reshmi Prem To: Ilya Varlashkin In-Reply-To: <37AF49F2-28AA-4858-83CA-E25380DC94E9@nobulus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-92336879-1307734746=:49492" Cc: IETF IDR , bruno.decraene@orange-ftgroup.com, Vinod Joseph , "raszuk@cisco.com Raszuk" , gaurav.thareja@gmail.com, Chintan.Shah@colt.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 19:39:19 -0000 --0-92336879-1307734746=:49492 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Illya: =A0 ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As lon= g as you don't do anything what other specification forbids, do you need to= describe every possible combination of features that could be used togethe= r? Today you can use ADD-PATH to send multiple PATHs, tomorrow there will b= e another solution to do it. NH SAFI neither forbids nor requires you to us= e any other BGP feature beyond what's specified in the drafts, so by all me= ans if you want multiple best PATHs from RR-client perspective you can comb= ine NH SAFI with ADD-PATH. If you don't need multiple paths, you just don't= use multiple paths. Do you feel this combination should be explicitly spel= led in the NH SAFI specs? =A0 >>>>>>>>>>>>>>> You are talking about using ADD-PATH to choose a select no.= of paths based only on admin costs that are statically specified on the PE= . This needs some work or integration or extension or whatever you call it,= to ADD-PATH. You need to mention this in your draft. =A0 ok, implicit assumption is that RR will use a) cost provided by RR-c; b) if= RR-c cost is unavailable for whatever reason RR will use its own cost. Not= e that original idea is that RR-c informs RR about all costs. If network po= licies call for non-IGP preference, then RR-c can use ever-increasing numbe= rs calculated in a way operator prefers. First N (number of preferred exits= ) can be explicitly configured on RR-c, the rest RR-c will calculate itself= by ordering IGP costs of remaining exits. To give an example: a PE prefers= NH5 and NH9, which operator configures on the PE manually. Let's say at so= me moment _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH5= 0. PE sends following info to RR: first it tells that NH5:cost1, NH9:cost2 = (because it configured by operator), then PE takes remaining next-hops and = arranges them in order of increasing IGP cost behind first two next-hops, t= he cost reported for NH-i to RR is the position of that NH-i in the just created list. When IGP cost to non-preferred next-hops changes (due t= o topology change), PE just re-evaluates NH order and sends updated cost to= RR. When preferred ASBR's are not available as feasible path to certain pr= efix, RR just uses whatever is next NH in the list received from RR-c but o= nly for prefixes where preferred ASBR is not feasible exit. When preferred = ASBR's fail (i.e. no path can be reached via them), RR uses for whatever is= next NH in the list received from RR-c for all prefixes. So in general, wh= en certain prefix cannot be reached via preferred ASBR's (regardless of the= reason) then RR uses next NH in the list received from RR-c. If for some r= eason connectivity from RR-c to ASBR fails, RR-c will inform RR that partic= ular NH is no longer feasible (as described in NH SAFI draft) and RR will s= top considering that ASBR when calculating routes for given RR-c (even if f= rom RR perspective or from any other router perspective that very same ASBR is still reachable). Same question as above - do you feel such b= ehaviour should be explicitly spelled out even though it's natural? =A0 >>>>>>>>>>>>>>>>I am lost sorry. Simple example: network has 10 ASBRs. PE1 = says ASBR1=3DMETRIC15 and ASBR2=3DMETRIC20 and sends this info to the RR. N= ow RR reflects both these ASBR paths to PE1 with the same metrics? =A0 >>>>>>>>>>>>>>>>>>>>PE1 automatically calculates IGP Cost to ASBR 3--10? >>>>>>>>>>>>>>>>>>>>>>> Assume ASBR 3-10 have metrics as follows ASBR3=3D3,= ASBR4=3D4 .....ASBR10=3D10, This can happen right?=20 =A0 >>>>>>>>>>>>>>>>>>>>>>>>>> RR advertises ASBR 3 TO ASBR 10 paths to PE1?=20 =A0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does RR ensure that non candidate (pref= erred paths) are not announced to the PE upfront? =A0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How do you ensure that non candidate paths= always have a higher metric than candidate paths? =A0 - Prem --- On Fri, 6/10/11, Ilya Varlashkin wrote: From: Ilya Varlashkin Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: "raszuk@cisco.com Raszuk" , "Vinod Joseph" , gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, C= hintan.Shah@colt.net, "IETF IDR" Date: Friday, June 10, 2011, 2:04 PM On Jun 10, 2011, at 19:21 , Reshmi Prem wrote: > Ilya, >=A0=20 > I did not see your draft specifying that you would be using ADD-PATH, Can= you confirm this? >=20 ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As lon= g as you don't do anything what other specification forbids, do you need to= describe every possible combination of features that could be used togethe= r? Today you can use ADD-PATH to send multiple PATHs, tomorrow there will b= e another solution to do it. NH SAFI neither forbids nor requires you to us= e any other BGP feature beyond what's specified in the drafts, so by all me= ans if you want multiple best PATHs from RR-client perspective you can comb= ine NH SAFI with ADD-PATH. If you don't need multiple paths, you just don't= use multiple paths. Do you feel this combination should be explicitly spel= led in the NH SAFI specs? > Vinod's draft specifies a means of using an RR specific RT to permit a RR= calculated best path in addition to RTC specified paths. How does your dra= ft handle this? What happens if the list of ASBRS that i indicate a metric = for disappear?? ok, implicit assumption is that RR will use a) cost provided by RR-c; b) if= RR-c cost is unavailable for whatever reason RR will use its own cost. Not= e that original idea is that RR-c informs RR about all costs. If network po= licies call for non-IGP preference, then RR-c can use ever-increasing numbe= rs calculated in a way operator prefers. First N (number of preferred exits= ) can be explicitly configured on RR-c, the rest RR-c will calculate itself= by ordering IGP costs of remaining exits. To give an example: a PE prefers= NH5 and NH9, which operator configures on the PE manually. Let's say at so= me moment _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH5= 0. PE sends following info to RR: first it tells that NH5:cost1, NH9:cost2 = (because it configured by operator), then PE takes remaining next-hops and = arranges them in order of increasing IGP cost behind first two next-hops, t= he cost reported for NH-i to RR is the position of that NH-i in the just created list. When IGP cost to non-preferred next-hops changes (due t= o topology change), PE just re-evaluates NH order and sends updated cost to= RR. When preferred ASBR's are not available as feasible path to certain pr= efix, RR just uses whatever is next NH in the list received from RR-c but o= nly for prefixes where preferred ASBR is not feasible exit. When preferred = ASBR's fail (i.e. no path can be reached via them), RR uses for whatever is= next NH in the list received from RR-c for all prefixes. So in general, wh= en certain prefix cannot be reached via preferred ASBR's (regardless of the= reason) then RR uses next NH in the list received from RR-c. If for some r= eason connectivity from RR-c to ASBR fails, RR-c will inform RR that partic= ular NH is no longer feasible (as described in NH SAFI draft) and RR will s= top considering that ASBR when calculating routes for given RR-c (even if f= rom RR perspective or from any other router perspective that very same ASBR is still reachable). Same question as above - do you feel such b= ehaviour should be explicitly spelled out even though it's natural? Kind regards, iLya --0-92336879-1307734746=:49492 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Ilya,
 
I did not see your draft specifying that you would be using ADD-PATH, = Can you confirm this?
 
Vinod's draft specifies a means of using an RR specific RT to permit a= RR calculated best path in addition to RTC specified paths. How does your = draft handle this? What happens if the list of ASBRS that i indicate a metr= ic for disappear??
 
Prem


--- On Fri, 6/10/11, Vinod Joseph <vjoseph@juniper.ne= t> wrote:

From: Vinod Joseph <vjoseph@juniper.net>Subject: RE: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To= : "iLya" <ilya@nobulus.com>, "Reshmi Prem" <reshmi_prem@yahoo.com&= gt;, raszuk@cisco.com
Cc: gaurav.thareja@gmail.com, bruno.decraene@orang= e-ftgroup.com, Chintan.Shah@colt.net, idr@ietf.org
Date: Friday, June 10= , 2011, 12:12 PM

Ilya and Prem,

if there are multiple non-pref= erred next-hops (which are not available via
preferred), then Vinod's d= raft would return routes based on RR's view of the
world

Vinod -= As with the NH draft where you need to define admin metrics on a per ASBR,= with the proposed draft you would need to identify potential ASBRs in the = network which you want to signal interest in.

the difference is in = this case NH SAFI draft will provide best route from
client's perspecti= ve, Vinod's draft will provide best route from RR
perspective.

V= inod - That's not correct, If a path belonging to an RT is withdrawn  = then the RR would announce another path ASBR path that matches the same RT.=

Regards

Vinod Joseph
Professional Services - Service Pro= vider Europe
Juniper Networks           =             &nb= sp;            =             &nb= sp;            =       
M: +44 (0) 7500 835 876
E: = vjoseph@juniper.net
 = ;



-----Original Message-----
From: iLya [mailto:ilya@nobulus.com]
Sent: 10 June 2011 = 17:18
To: Reshmi Prem; raszuk@cisco.com
Cc: gaurav.thareja@gmail.com; bruno.= decraene@orange-ftgroup.com; Chintan.Shah@colt.net; Vinod Joseph; = idr@ietf.org
Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-rou= te-reflection

--------------------------------------------------
= > With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a=
> Route Target assignment. Multiple paths can be announced as per R= TC. Would
> be keen to understand how the local PE would handle best path selection - =
> Local weights per RT, Local policy on PE??.
>

if ther= e are multiple non-preferred next-hops (which are not available via
pre= ferred), then Vinod's draft would return routes based on RR's view of the <= BR>world

> NH Draft: No policy on RR, only PEs need to be manuall= y configured with
> admin costs and RR does reflect best paths based= on these values. Concern:
> With vinod's draft, an RT can mean more= than a single ASBR, but with NH
> draft, each ASBR path needed in t= he PE needs to be configured with an
> Admin cost, so more work. Add= -path used for announcing multiple paths
> (illiya mentioned it).>
Note that with NH draft you indeed configure N preferences on each= of K PE,
but nothing on ASBRs, so in total O(N*K)complexity. With RT y= ou configure 1
RT (assuming that RT-default is always wanted by default) on each of K PE
and M RT on each L ASBR, so in total O(K+M*L)= complexity. If you want two
preferred exits for 100 PE (PE's don't hav= e to have same preferences) then
200 steps in case of NH draft regardle= ss of number of ASBR's. If you have
100 PE's and 50 ASBR's then you hav= e 150 steps in case of Vinod's draft. I
think 200 (NH) vs 150 (Vinod) s= teps is price worth paying for getting best
route (in case of NH draft)= from client's perspective in case destination
prefix is not available = over preferred path. Should you think the numbers in
my example are low= , I'd be interested to see realistic scenario where
numbers will be sig= nificantly higher.


> Both NH and Vinod's ORR draft still spec= ify that in the event of an ASBR
> path being withdrawn, an addition= al path will be advertised since this is
> the default behavior of A= DD-PATH - So Vinod's draft and NH draft are not
> doing something novel from what Add-Path specifies.
>

the differenc= e is in this case NH SAFI draft will provide best route from
client's p= erspective, Vinod's draft will provide best route from RR
perspective.<= BR>
Kind regards,
iLya


Illya:
 
ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. A= s long as you don't do anything what other specification forbids, do you ne= ed to describe every possible combination of features that could be used to= gether? Today you can use ADD-PATH to send multiple PATHs, tomorrow there w= ill be another solution to do it. NH SAFI neither forbids nor requires you = to use any other BGP feature beyond what's specified in the drafts, so by a= ll means if you want multiple best PATHs from RR-client perspective you can= combine NH SAFI with ADD-PATH. If you don't need multiple paths, you just = don't use multiple paths. Do you feel this combination should be explicitly= spelled in the NH SAFI specs?
 
>>>>>>>>>>>>>>> You are t= alking about using ADD-PATH to choose a select no. of paths based only on a= dmin costs that are statically specified on the PE. This needs some work or= integration or extension or whatever you call it, to ADD-PATH. You need to= mention this in your draft.
 
ok, implicit assumption is that RR will use a) cost provided by RR-c; = b) if RR-c cost is unavailable for whatever reason RR will use its own cost= . Note that original idea is that RR-c informs RR about all costs. If netwo= rk policies call for non-IGP preference, then RR-c can use ever-increasing = numbers calculated in a way operator prefers. First N (number of preferred = exits) can be explicitly configured on RR-c, the rest RR-c will calculate i= tself by ordering IGP costs of remaining exits. To give an example: a PE pr= efers NH5 and NH9, which operator configures on the PE manually. Let's say = at some moment _all_ prefixes are reachable via set of next-hops NH1,NH2,..= .,NH50. PE sends following info to RR: first it tells that NH5:cost1, NH9:c= ost2 (because it configured by operator), then PE takes remaining next-hops= and arranges them in order of increasing IGP cost behind first two next-ho= ps, the cost reported for NH-i to RR is the position of that NH-i in the just created list. When IGP cost to non-preferred next-hops changes (d= ue to topology change), PE just re-evaluates NH order and sends updated cos= t to RR. When preferred ASBR's are not available as feasible path to certai= n prefix, RR just uses whatever is next NH in the list received from RR-c b= ut only for prefixes where preferred ASBR is not feasible exit. When prefer= red ASBR's fail (i.e. no path can be reached via them), RR uses for whateve= r is next NH in the list received from RR-c for all prefixes. So in general= , when certain prefix cannot be reached via preferred ASBR's (regardless of= the reason) then RR uses next NH in the list received from RR-c. If for so= me reason connectivity from RR-c to ASBR fails, RR-c will inform RR that pa= rticular NH is no longer feasible (as described in NH SAFI draft) and RR wi= ll stop considering that ASBR when calculating routes for given RR-c (even = if from RR perspective or from any other router perspective that very same ASBR is still reachable). Same question as above - do you feel s= uch behaviour should be explicitly spelled out even though it's natural?
 
>>>>>>>>>>>>>>>>I am l= ost sorry. Simple example: network has 10 ASBRs. PE1 says ASBR1=3DMETRIC15 = and ASBR2=3DMETRIC20 and sends this info to the RR. Now RR reflects both th= ese ASBR paths to PE1 with the same metrics?
 
>>>>>>>>>>>>>>>>>&g= t;>>PE1 automatically calculates IGP Cost to ASBR 3--10?
>>>>>>>>>>>>>>>>>&g= t;>>>>> Assume ASBR 3-10 have metrics as follows ASBR3=3D3, = ASBR4=3D4 .....ASBR10=3D10, This can happen right?
 
>>>>>>>>>>>>>>>>>&g= t;>>>>>>>> RR advertises ASBR 3 TO ASBR 10 paths to= PE1?
 
>>>>>>>>>>>>>>>>>&g= t;>>>>>>>>>>>>> How does RR ensure t= hat non candidate (preferred paths) are not announced to the PE upfront?
 
>>>>>>>>>>>>>>>>>&g= t;>>>>>>>>>>>>>> How do you ensur= e that non candidate paths always have a higher metric than candidate paths= ?
 
- Prem

--- On Fri, 6/10/11, Ilya Varlashkin <ilya@nobu= lus.com> wrote:

From: Ilya Varlashkin <ilya@nobulus.com>Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection
To= : "Reshmi Prem" <reshmi_prem@yahoo.com>
Cc: "raszuk@cisco.com Rasz= uk" <raszuk@cisco.com>, "Vinod Joseph" <vjoseph@juniper.net>, g= aurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@co= lt.net, "IETF IDR" <idr@ietf.org>
Date: Friday, June 10, 2011, 2:0= 4 PM

On Jun 10, 2011, at 19:21 , Reshmi Prem wrote:
> Ilya,
> 
> I did not see your draft specifying tha= t you would be using ADD-PATH, Can you confirm this?
>

ehrm..= .use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As long as y= ou don't do anything what other specification forbids, do you need to descr= ibe every possible combination of features that could be used together? Tod= ay you can use ADD-PATH to send multiple PATHs, tomorrow there will be anot= her solution to do it. NH SAFI neither forbids nor requires you to use any = other BGP feature beyond what's specified in the drafts, so by all means if= you want multiple best PATHs from RR-client perspective you can combine NH= SAFI with ADD-PATH. If you don't need multiple paths, you just don't use m= ultiple paths. Do you feel this combination should be explicitly spelled in= the NH SAFI specs?

> Vinod's draft specifies a means of using an RR specific RT to permit a RR calculated best path in addition to= RTC specified paths. How does your draft handle this? What happens if the = list of ASBRS that i indicate a metric for disappear??

ok, implicit = assumption is that RR will use a) cost provided by RR-c; b) if RR-c cost is= unavailable for whatever reason RR will use its own cost. Note that origin= al idea is that RR-c informs RR about all costs. If network policies call f= or non-IGP preference, then RR-c can use ever-increasing numbers calculated= in a way operator prefers. First N (number of preferred exits) can be expl= icitly configured on RR-c, the rest RR-c will calculate itself by ordering = IGP costs of remaining exits. To give an example: a PE prefers NH5 and NH9,= which operator configures on the PE manually. Let's say at some moment _al= l_ prefixes are reachable via set of next-hops NH1,NH2,...,NH50. PE sends f= ollowing info to RR: first it tells that NH5:cost1, NH9:cost2 (because it configured by operator), then PE takes remaining next-hops and= arranges them in order of increasing IGP cost behind first two next-hops, = the cost reported for NH-i to RR is the position of that NH-i in the just c= reated list. When IGP cost to non-preferred next-hops changes (due to topol= ogy change), PE just re-evaluates NH order and sends updated cost to RR. Wh= en preferred ASBR's are not available as feasible path to certain prefix, R= R just uses whatever is next NH in the list received from RR-c but only for= prefixes where preferred ASBR is not feasible exit. When preferred ASBR's = fail (i.e. no path can be reached via them), RR uses for whatever is next N= H in the list received from RR-c for all prefixes. So in general, when cert= ain prefix cannot be reached via preferred ASBR's (regardless of the reason= ) then RR uses next NH in the list received from RR-c. If for some reason c= onnectivity from RR-c to ASBR fails, RR-c will inform RR that particular NH is no longer feasible (as described in NH SAFI draft) and RR= will stop considering that ASBR when calculating routes for given RR-c (ev= en if from RR perspective or from any other router perspective that very sa= me ASBR is still reachable). Same question as above - do you feel such beha= viour should be explicitly spelled out even though it's natural?

Kin= d regards,
iLya

--0-92336879-1307734746=:49492-- From raszuk@cisco.com Fri Jun 10 13:12:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2153011E819B for ; Fri, 10 Jun 2011 13:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMCfFVU54rsw for ; Fri, 10 Jun 2011 13:12:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 76DA711E807C for ; Fri, 10 Jun 2011 13:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=178; q=dns/txt; s=iport; t=1307736758; x=1308946358; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+jo03bv/5HnaOyIJBIqIFj+FmHTexPyDxU7GizSiZoc=; b=C43awZaH8/1vvEhrc/F+dJ4MZwTrK818AHixUNzyBNknKy30vadesBTM m36zmlU3DfsqdX2obZuXwuzeqQGRz/jZIyxo37UGd9n5coIBvukEt/EQf dwABNvy3eWUjfR/DOxVsf+BCmHbehOuQ5bdkf/0pyv/MEr5f6ZRX/a/NJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEd68k2rRDoJ/2dsb2JhbABSpk13pxSDDg8BmmiGIwSRK4ROiws X-IronPort-AV: E=Sophos;i="4.65,348,1304294400"; d="scan'208";a="463565459" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2011 20:12:38 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5AKCa4M002210; Fri, 10 Jun 2011 20:12:36 GMT Message-ID: <4DF27ACA.4000105@cisco.com> Date: Fri, 10 Jun 2011 22:12:58 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <84094.24987.qm@web37908.mail.mud.yahoo.com> In-Reply-To: <84094.24987.qm@web37908.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 20:12:39 -0000 Hi Reshmi, Since you have been referring many times today that you are an operator may I ask what is the AS number of the network you manage or engineer ? Many thx, R. From vjoseph@juniper.net Fri Jun 10 13:29:21 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE70411E807D for ; Fri, 10 Jun 2011 13:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.056 X-Spam-Level: X-Spam-Status: No, score=-6.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7If7-1dI6x0L for ; Fri, 10 Jun 2011 13:29:21 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id C041011E8105 for ; Fri, 10 Jun 2011 13:29:11 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTfJ+l9f4k4qvg8KDhnuq6ZfLoF74WCqz@postini.com; Fri, 10 Jun 2011 13:29:20 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Fri, 10 Jun 2011 13:28:47 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 21:28:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jun 2011 21:28:38 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FDAD@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwnifMrqUm/arTBSSav0dlqH0YAoQABRZ9QAAdvZiA= References: <924687.99284.qm@web37906.mail.mud.yahoo.com> <7F84B2FDB6554F3F8203DB64E626AB72@hnivarlas1> <90D18849576F6C41A6178B62DECAFD0F1BBDD2B9@emailemea4.jnpr.net> From: Vinod Joseph To: iLya , Reshmi Prem , X-OriginalArrivalTime: 10 Jun 2011 20:28:46.0247 (UTC) FILETIME=[FF914370:01CC27AC] Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 20:29:21 -0000 Hi Prem, Your question on path selection on the local PE will be elaborated in = the following version of the draft to be released shortly. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Vinod Joseph=20 Sent: 10 June 2011 18:13 To: iLya; Reshmi Prem; raszuk@cisco.com Cc: gaurav.thareja@gmail.com; bruno.decraene@orange-ftgroup.com; = Chintan.Shah@colt.net; idr@ietf.org Subject: RE: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection Ilya and Prem, if there are multiple non-preferred next-hops (which are not available = via=20 preferred), then Vinod's draft would return routes based on RR's view of = the=20 world Vinod - As with the NH draft where you need to define admin metrics on a = per ASBR, with the proposed draft you would need to identify potential = ASBRs in the network which you want to signal interest in.=20 the difference is in this case NH SAFI draft will provide best route = from=20 client's perspective, Vinod's draft will provide best route from RR=20 perspective. Vinod - That's not correct, If a path belonging to an RT is withdrawn = then the RR would announce another path ASBR path that matches the same = RT.=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: iLya [mailto:ilya@nobulus.com]=20 Sent: 10 June 2011 17:18 To: Reshmi Prem; raszuk@cisco.com Cc: gaurav.thareja@gmail.com; bruno.decraene@orange-ftgroup.com; = Chintan.Shah@colt.net; Vinod Joseph; idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection -------------------------------------------------- > With Vinod's ORR Draft: No policies on the RR. New ASBR added, needs a = > Route Target assignment. Multiple paths can be announced as per RTC. = Would=20 > be keen to understand how the local PE would handle best path = selection -=20 > Local weights per RT, Local policy on PE??. > if there are multiple non-preferred next-hops (which are not available = via=20 preferred), then Vinod's draft would return routes based on RR's view of = the=20 world > NH Draft: No policy on RR, only PEs need to be manually configured = with=20 > admin costs and RR does reflect best paths based on these values. = Concern:=20 > With vinod's draft, an RT can mean more than a single ASBR, but with = NH=20 > draft, each ASBR path needed in the PE needs to be configured with an=20 > Admin cost, so more work. Add-path used for announcing multiple paths=20 > (illiya mentioned it). > Note that with NH draft you indeed configure N preferences on each of K = PE,=20 but nothing on ASBRs, so in total O(N*K)complexity. With RT you = configure 1=20 RT (assuming that RT-default is always wanted by default) on each of K = PE=20 and M RT on each L ASBR, so in total O(K+M*L) complexity. If you want = two=20 preferred exits for 100 PE (PE's don't have to have same preferences) = then=20 200 steps in case of NH draft regardless of number of ASBR's. If you = have=20 100 PE's and 50 ASBR's then you have 150 steps in case of Vinod's draft. = I=20 think 200 (NH) vs 150 (Vinod) steps is price worth paying for getting = best=20 route (in case of NH draft) from client's perspective in case = destination=20 prefix is not available over preferred path. Should you think the = numbers in=20 my example are low, I'd be interested to see realistic scenario where=20 numbers will be significantly higher. > Both NH and Vinod's ORR draft still specify that in the event of an = ASBR=20 > path being withdrawn, an additional path will be advertised since this = is=20 > the default behavior of ADD-PATH - So Vinod's draft and NH draft are = not=20 > doing something novel from what Add-Path specifies. > the difference is in this case NH SAFI draft will provide best route = from=20 client's perspective, Vinod's draft will provide best route from RR=20 perspective. Kind regards, iLya =20 From raszuk@cisco.com Fri Jun 10 15:04:56 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572BE11E81D4 for ; Fri, 10 Jun 2011 15:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZMXjXVswLUK for ; Fri, 10 Jun 2011 15:04:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7226F11E81A0 for ; Fri, 10 Jun 2011 15:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=807; q=dns/txt; s=iport; t=1307743495; x=1308953095; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/jqeP/xkF332QAzJvVuon0poU63Z5qjNLtcTk6TtHLk=; b=hC9nxuIdqICjkHy52HwxGnzA+kj1VaKrOpNGpUQG02SWJYiiEiMnImr8 Y/gC5jGXACCtR0OuvZtke23Cs8YXNdwssUGaeq1hJ6007xnMxyQmiTN8T MJoqJ7JnUxZJayOVZzaZhWopn51MjDWnqORbZN4r4vmE7Bui1lGKeqkso s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP6T8k2rRDoG/2dsb2JhbABSpk13iHKdVIMODwGaaYYjBJErhE6LCw X-IronPort-AV: E=Sophos;i="4.65,349,1304294400"; d="scan'208";a="463615475" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2011 22:04:55 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5AM4rE5009670; Fri, 10 Jun 2011 22:04:53 GMT Message-ID: <4DF2951B.6010809@cisco.com> Date: Sat, 11 Jun 2011 00:05:15 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <717474.30883.qm@web37908.mail.mud.yahoo.com> In-Reply-To: <717474.30883.qm@web37908.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, vjoseph@juniper.net, idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 22:04:56 -0000 Hi Reshmi, Coming back to our discussion in the morning I have one clarification question. > I have been following this discussion and I would like add my opinions here > We have been having similar requirements to steer traffic through > selective exit points in the network which are driven by customer > requirements, example having premium customers use a set of ASBRS vs. a > different set of other customers using another set of ASBRs within a > given region/POP or whatever you may like to call it. In effect, IGP > metric may not always be the the choice in our case. Do you see a case where on the same PE which both premium and not so premium customers are attached to your network policy would require them to exit via different ASBRs out of your network ? Many thx, R. From raszuk@cisco.com Sat Jun 11 12:28:34 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E41411E8210 for ; Sat, 11 Jun 2011 12:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.487 X-Spam-Level: X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PjW8H1nz34P for ; Sat, 11 Jun 2011 12:28:34 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 077ED11E81F7 for ; Sat, 11 Jun 2011 12:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=708; q=dns/txt; s=iport; t=1307820513; x=1309030113; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9no7SmxpCrnDDteSJ8QorOJhn8kbuAb4Ebzcud3iRDo=; b=lhim+K2i79JfL0Q7qPvQvCoeLknLwOnQKYz8O5oZGYzG5bz6RKb5waVG ouNglVDm0fkO2HWFoqt69LFLRpjCjwtKwwIcHQeqNWT3Zv7t/DnfQe2SG juNYcC7z6r49ZKpLlZh4U/j2ecHSPAZvuzBe5x4KZDL5BCOXscVBbN36e 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAObA802rRDoG/2dsb2JhbABSpk93iHKiMIMODwGaEoYkBJE0hE+LEA X-IronPort-AV: E=Sophos;i="4.65,353,1304294400"; d="scan'208";a="335047387" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 11 Jun 2011 19:28:33 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5BJSWuo004404; Sat, 11 Jun 2011 19:28:33 GMT Message-ID: <4DF3C1F7.8040509@cisco.com> Date: Sat, 11 Jun 2011 21:28:55 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <90D18849576F6C41A6178B62DECAFD0F1BBDD2A1@emailemea4.jnpr.net> <5DD781A4BE13384A900438DF0608972C069971D4@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C069971D4@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection (shortest IGP vs policy based routing) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 19:28:34 -0000 Hi Vinod, > Vinod# Policy driven path selection is configured on the PEs/ASBRs > (BGP speakers) using Route Targets (configured) and RT Constrain. The > RR responds with a list of paths that match the RTs indicated - it > could be a list, range or the default RT. The RR computes this > information and advertises needed information to BGP speakers. There > is no propagation needed between individual BGP speakers in the > network, and is only needed between BGP Speakers to RR. As Route Target Ext Community is a transitive BGP community can you clarify what mechanism are you going to use to prevent distribution of Route Targets outside of the autonomous system boundaries ? Thx, R. From jakob.heitz@ericsson.com Sun Jun 12 09:43:20 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03A51F0C45 for ; Sun, 12 Jun 2011 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1UBXS1YNGua for ; Sun, 12 Jun 2011 09:43:20 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0921F0C35 for ; Sun, 12 Jun 2011 09:43:20 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5CGhEN5028167; Sun, 12 Jun 2011 11:43:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 12 Jun 2011 12:43:09 -0400 From: Jakob Heitz To: "stephane.litkowski@orange-ftgroup.com" Date: Sun, 12 Jun 2011 12:43:11 -0400 Thread-Topic: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpH8+8i91es1ysTDayY0Qsx5IiAg== Message-ID: References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36EE3646A09DAA60429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36EE3646A09DAA60429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> 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 Cc: "idr@ietf.org" , "laurent.lavallee@sns.bskyb.com" , Vinod Joseph , "raszuk@cisco.com" , Amit Khopkar , "Chintan.Shah@colt.net" , "Thareja, Gaurav" Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 16:43:20 -0000 Has this been answered? -- Jakob Heitz. On Jun 8, 2011, at 6:33 AM, "stephane.litkowski@orange-ftgroup.com" wrote: > Thanks for the feedback. >=20 > Regarding RTC behavior, I don't agree of your interpretation of the way i= t works, you said : "There is no best path calculation when using RT constr= ain. The RR just picks the number of paths that match a given RT and advert= ise this to the PE." > Maybe I'm wrong, but I hope Robert will correct us as he is one of people= who defined RTC :) > For me, RTC doesn't change anything to the way BGP is globally working. R= TC was designed to work for VPNs (first IPv4 but now it can be used for all= VPN types). RTC is just a way to signal an interrest for a BGP speaker for= a specific set of VPN prefixes matching some RTs (with end to end possibil= ity to propagate it). This signalling will lead for the peer who received t= he RT NLRI to install a per peer ORF. And imo that's all. > So if you take this case (VPN) : >=20 > PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between them) > PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. >=20 > RR1 owns VPN routes and has the followings : > RD1:X/Y label z > Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 > Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT2 >=20 > RD2:A/B label C > Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 >=20 > RD3:A/B label D > Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT1 >=20 > RR1 still compute best path per VPN prefix (in your case it will be IPv4 = but it doesn't really matter). > RD1:X/Y label z -> Path2 is best > RD2:A/B label C -> Path1 > RD3:A/B label D -> Path2 > Then RR1 will advertise these best path to the peers, especially PE1, but= it has an ORF for PE1 which match only RT1, so only RD2:A/B and RD3:A/B wi= ll be sent, RD1:X/Y will not because it doesn't have the community. >=20 >=20 > What I mean by this, is that if you consider your case (IPv4), you will h= ave this : >=20 > PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked with RT= 1 and ASBR2 marked with RT2. > PE1 will signal his interrested for RT1 and RT2. >=20 > RR1 owns all IPv4 path from ASBRs, if we consider only one prefix X/Y rec= eived from all the ASBRs, we have this : > X/Y > Path 1 -> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 > Path 2 -> NH=3DASBR2 (IGP cost b), LP 100, ASPATH b, RT2 > Path 3 -> NH=3DASBR3 (IGP cost c), LP 100, ASPATH c, RT3 > ... > Path x -> NH=3DASBRx (IGP cost x), LP 100, ASPATH x, RTx >=20 > RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 peer. > RR1 selects best path for all prefixes, and so for X/Y, it will choose on= e path, the best for him, based on his own criteria. So if it selects for e= xample Path3 as best, no path will be exported to PE1 :( >=20 > All, pls correct me if I'm wrong. >=20 >=20 > Thanks, >=20 From vjoseph@juniper.net Sun Jun 12 10:12:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1A311E80E8 for ; Sun, 12 Jun 2011 10:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[AWL=-1.569, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GitqCpRt4OXT for ; Sun, 12 Jun 2011 10:12:33 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id AACB711E80AE for ; Sun, 12 Jun 2011 10:12:23 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTfTzdDswKlKSkGNqvScfDJrN379Y9BZY@postini.com; Sun, 12 Jun 2011 10:12:31 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 10:09:12 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 18:09:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 18:09:03 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpH8+8i91es1ysTDayY0Qsx5IiAgAArh6A References: <5DD781A4BE13384A900438DF0608972C06996C9A@emailemea4.jnpr.net> <089ECC17A6704F10A9D5F3D09BBB8BD6@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996CEE@emailemea4.jnpr.net> <44EE199F-BA36-45A4-AE98-6C4103E33139@nobulus.com> <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC 3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> From: Vinod Joseph To: Jakob Heitz , X-OriginalArrivalTime: 12 Jun 2011 17:09:10.0777 (UTC) FILETIME=[72750E90:01CC2923] Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, raszuk@cisco.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 17:12:33 -0000 Yes it has been Jacob. The proposal uses ADD-PATH in combination with RTC - Therefore if a PE = signals interest in a given RT (ASBRs), the RR will use ADD-PATH in = order to make sure that NO best path calculation is used to tie-break = between multiple paths within the same RT and in effect announce all or = "N" paths (that can be configured on a per Peer/Peer-Group) basis to the = PE. Let me also re-iterate that a BGP speaker does not need to have a "RT" = configured, if it does not intend to add an extended community to any of = its announced prefixes, but will have the ability to use RT constrain to = indicate a list of RTs it is interested in. In other words, only ASBRs = may have Route Targets configured, and all PE may just use RTC to = indicate preferences in a list of given ASBRs.=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Sent: 12 June 2011 17:43 To: stephane.litkowski@orange-ftgroup.com Cc: Vinod Joseph; raszuk@cisco.com; idr@ietf.org; Thareja, Gaurav; Amit = Khopkar; Chintan.Shah@colt.net; laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection Has this been answered? -- Jakob Heitz. On Jun 8, 2011, at 6:33 AM, "stephane.litkowski@orange-ftgroup.com" = wrote: > Thanks for the feedback. >=20 > Regarding RTC behavior, I don't agree of your interpretation of the = way it works, you said : "There is no best path calculation when using = RT constrain. The RR just picks the number of paths that match a given = RT and advertise this to the PE." > Maybe I'm wrong, but I hope Robert will correct us as he is one of = people who defined RTC :) > For me, RTC doesn't change anything to the way BGP is globally = working. RTC was designed to work for VPNs (first IPv4 but now it can be = used for all VPN types). RTC is just a way to signal an interrest for a = BGP speaker for a specific set of VPN prefixes matching some RTs (with = end to end possibility to propagate it). This signalling will lead for = the peer who received the RT NLRI to install a per peer ORF. And imo = that's all. > So if you take this case (VPN) : >=20 > PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between them) > PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. >=20 > RR1 owns VPN routes and has the followings : > RD1:X/Y label z > Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 > Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT2 >=20 > RD2:A/B label C > Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 >=20 > RD3:A/B label D > Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, RT1 >=20 > RR1 still compute best path per VPN prefix (in your case it will be = IPv4 but it doesn't really matter). > RD1:X/Y label z -> Path2 is best > RD2:A/B label C -> Path1 > RD3:A/B label D -> Path2 > Then RR1 will advertise these best path to the peers, especially PE1, = but it has an ORF for PE1 which match only RT1, so only RD2:A/B and = RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the = community. >=20 >=20 > What I mean by this, is that if you consider your case (IPv4), you = will have this : >=20 > PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked with = RT1 and ASBR2 marked with RT2. > PE1 will signal his interrested for RT1 and RT2. >=20 > RR1 owns all IPv4 path from ASBRs, if we consider only one prefix X/Y = received from all the ASBRs, we have this : > X/Y > Path 1 -> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, = RT1 > Path 2 -> NH=3DASBR2 (IGP cost b), LP 100, ASPATH b, = RT2 > Path 3 -> NH=3DASBR3 (IGP cost c), LP 100, ASPATH c, = RT3 > ... > Path x -> NH=3DASBRx (IGP cost x), LP 100, ASPATH x, = RTx >=20 > RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 peer. > RR1 selects best path for all prefixes, and so for X/Y, it will choose = one path, the best for him, based on his own criteria. So if it selects = for example Path3 as best, no path will be exported to PE1 :( >=20 > All, pls correct me if I'm wrong. >=20 >=20 > Thanks, >=20 From raszuk@cisco.com Sun Jun 12 11:44:23 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DA211E810C for ; Sun, 12 Jun 2011 11:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.401 X-Spam-Level: X-Spam-Status: No, score=-8.401 tagged_above=-999 required=5 tests=[AWL=-1.981, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oJb8tnlRXIE for ; Sun, 12 Jun 2011 11:44:22 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id E57AB11E810A for ; Sun, 12 Jun 2011 11:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=6021; q=dns/txt; s=iport; t=1307904262; x=1309113862; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tPPK9D9niAtWbSC7N6X64fm5MjHy7KKaTWlF8gQjsWk=; b=H4H8/fdvEeqkbd/P5TVEOJWfV7Q9ZLxlWeTt8WFgidVXbZTlanVJahbN 6+2f2n4sYnFHkHj7B61WeveuGFeqyNCvmLTheeBVV/477/N+Q5itWL1bj Ew0VeZA+egK4hfCmSjSPf0iC8eMoDWv/M4rXGfRK6mykAUIIL0+DfDjbP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOAI9U2rRDoG/2dsb2JhbABSpk93iHKiIYMODwGZYoYkBJE0hE+LEA X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="375114335" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2011 18:44:18 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5CIiFso012041; Sun, 12 Jun 2011 18:44:16 GMT Message-ID: <4DF50900.6080302@cisco.com> Date: Sun, 12 Jun 2011 20:44:16 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 18:44:24 -0000 Hi Vinod, Bruno interpretation is correct your is I am afraid wrong even to your own implementation of RTC. RTC does not modify best path calculation. For VPN in the even there would be overlapping VPNv4 nets different RD per VRF solves the problem of different path with different RT being selected as overall best and dropped by RTC. Perhaps operators may speak if they are using different RDs in case there would be two different VPNv4 paths for the same net or not today with RTC. When you explained how draft-vinod is to work I assumed and took as obvious that you are calling for modification to how RTC works today for AFI/SAFIs draft-vinod would be applicable for. Someone asked if you are going to issue a new RTC spec to address this, but that AFAIK was never answered. > Let me also re-iterate that a BGP speaker does not need to have a > "RT" configured, if it does not intend to add an extended community > to any of its announced prefixes, but will have the ability to use RT > constrain to indicate a list of RTs it is interested in. You contradicting yourself. In order to use RTC for signaling on the interested set of RTs those I am afraid need to be configured. > words, only ASBRs may have Route Targets configured, and all PE may > just use RTC to indicate preferences in a list of given ASBRs. RTC is not a cristal ball. When we wrote it we were thinking about adding some magic to it, but since it would even further delay review and release of the spec we concluded that we will leave it for later time ;-). Perhaps the time is now ! Cheers, R. > Yes it has been Jacob. > > The proposal uses ADD-PATH in combination with RTC - Therefore if a > PE signals interest in a given RT (ASBRs), the RR will use ADD-PATH > in order to make sure that NO best path calculation is used to > tie-break between multiple paths within the same RT and in effect > announce all or "N" paths (that can be configured on a per > Peer/Peer-Group) basis to the PE. > > Let me also re-iterate that a BGP speaker does not need to have a > "RT" configured, if it does not intend to add an extended community > to any of its announced prefixes, but will have the ability to use RT > constrain to indicate a list of RTs it is interested in. In other > words, only ASBRs may have Route Targets configured, and all PE may > just use RTC to indicate preferences in a list of given ASBRs. > > Regards > > Vinod Joseph Professional Services - Service Provider Europe Juniper > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net > > > > -----Original Message----- From: Jakob Heitz > [mailto:jakob.heitz@ericsson.com] Sent: 12 June 2011 17:43 To: > stephane.litkowski@orange-ftgroup.com Cc: Vinod Joseph; > raszuk@cisco.com; idr@ietf.org; Thareja, Gaurav; Amit Khopkar; > Chintan.Shah@colt.net; laurent.lavallee@sns.bskyb.com Subject: Re: > [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection > > Has this been answered? > > -- Jakob Heitz. > > > On Jun 8, 2011, at 6:33 AM, > "stephane.litkowski@orange-ftgroup.com" > wrote: > >> Thanks for the feedback. >> >> Regarding RTC behavior, I don't agree of your interpretation of the >> way it works, you said : "There is no best path calculation when >> using RT constrain. The RR just picks the number of paths that >> match a given RT and advertise this to the PE." Maybe I'm wrong, >> but I hope Robert will correct us as he is one of people who >> defined RTC :) For me, RTC doesn't change anything to the way BGP >> is globally working. RTC was designed to work for VPNs (first IPv4 >> but now it can be used for all VPN types). RTC is just a way to >> signal an interrest for a BGP speaker for a specific set of VPN >> prefixes matching some RTs (with end to end possibility to >> propagate it). This signalling will lead for the peer who received >> the RT NLRI to install a per peer ORF. And imo that's all. So if >> you take this case (VPN) : >> >> PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between >> them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. >> >> RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 >> -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 >> (IGP cost 5), LP100, ASPATH empty, RT2 >> >> RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, >> RT1 >> >> RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, >> RT1 >> >> RR1 still compute best path per VPN prefix (in your case it will be >> IPv4 but it doesn't really matter). RD1:X/Y label z -> Path2 is >> best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 >> will advertise these best path to the peers, especially PE1, but it >> has an ORF for PE1 which match only RT1, so only RD2:A/B and >> RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the >> community. >> >> >> What I mean by this, is that if you consider your case (IPv4), you >> will have this : >> >> PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked >> with RT1 and ASBR2 marked with RT2. PE1 will signal his interrested >> for RT1 and RT2. >> >> RR1 owns all IPv4 path from ASBRs, if we consider only one prefix >> X/Y received from all the ASBRs, we have this : X/Y Path 1 -> >> NH=ASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=ASBR2 >> (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=ASBR3 (IGP cost >> c), LP 100, ASPATH c, RT3 ... Path x -> NH=ASBRx (IGP cost x), LP >> 100, ASPATH x, RTx >> >> RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 >> peer. RR1 selects best path for all prefixes, and so for X/Y, it >> will choose one path, the best for him, based on his own criteria. >> So if it selects for example Path3 as best, no path will be >> exported to PE1 :( >> >> All, pls correct me if I'm wrong. >> >> >> Thanks, >> > From vjoseph@juniper.net Sun Jun 12 11:49:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A843C11E810A for ; Sun, 12 Jun 2011 11:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.927 X-Spam-Level: X-Spam-Status: No, score=-3.927 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2J2qoluqbwM for ; Sun, 12 Jun 2011 11:49:33 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9959811E810D for ; Sun, 12 Jun 2011 11:49:25 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUKM2G8JNPphDj+hQkdrJDGZy/OboVB@postini.com; Sun, 12 Jun 2011 11:49:32 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 11:49:22 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 19:49:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 19:49:14 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpMMIEX85ywh5hRQWQQ01SVrXRhgAAC3OQ References: <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> From: Vinod Joseph To: X-OriginalArrivalTime: 12 Jun 2011 18:49:21.0199 (UTC) FILETIME=[70F2ABF0:01CC2931] Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 18:49:33 -0000 When you explained how draft-vinod is to work I assumed and took as=20 obvious that you are calling for modification to how RTC works today for = AFI/SAFIs draft-vinod would be applicable for. Yes that's correct, we are calling for modification to the present RTC = implementation. This was answered since when we were speaking about the = RR specific RT, which can be signalled via RTC - In this case, the RR is = to only announce the best path for a given prefix and this different to = the present behaviour of RTC and will need to be modified. Someone asked if you are going to issue a new RTC spec to address this,=20 but that AFAIK was never answered. Yes that is correct.=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 19:44 To: Vinod Joseph Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection Hi Vinod, Bruno interpretation is correct your is I am afraid wrong even to your=20 own implementation of RTC. RTC does not modify best path calculation. For VPN in the even there=20 would be overlapping VPNv4 nets different RD per VRF solves the problem=20 of different path with different RT being selected as overall best and=20 dropped by RTC. Perhaps operators may speak if they are using different=20 RDs in case there would be two different VPNv4 paths for the same net or = not today with RTC. When you explained how draft-vinod is to work I assumed and took as=20 obvious that you are calling for modification to how RTC works today for = AFI/SAFIs draft-vinod would be applicable for. Someone asked if you are going to issue a new RTC spec to address this,=20 but that AFAIK was never answered. > Let me also re-iterate that a BGP speaker does not need to have a > "RT" configured, if it does not intend to add an extended community > to any of its announced prefixes, but will have the ability to use RT > constrain to indicate a list of RTs it is interested in. You contradicting yourself. In order to use RTC for signaling on the=20 interested set of RTs those I am afraid need to be configured. > words, only ASBRs may have Route Targets configured, and all PE may > just use RTC to indicate preferences in a list of given ASBRs. RTC is not a cristal ball. When we wrote it we were thinking about=20 adding some magic to it, but since it would even further delay review=20 and release of the spec we concluded that we will leave it for later=20 time ;-). Perhaps the time is now ! Cheers, R. > Yes it has been Jacob. > > The proposal uses ADD-PATH in combination with RTC - Therefore if a > PE signals interest in a given RT (ASBRs), the RR will use ADD-PATH > in order to make sure that NO best path calculation is used to > tie-break between multiple paths within the same RT and in effect > announce all or "N" paths (that can be configured on a per > Peer/Peer-Group) basis to the PE. > > Let me also re-iterate that a BGP speaker does not need to have a > "RT" configured, if it does not intend to add an extended community > to any of its announced prefixes, but will have the ability to use RT > constrain to indicate a list of RTs it is interested in. In other > words, only ASBRs may have Route Targets configured, and all PE may > just use RTC to indicate preferences in a list of given ASBRs. > > Regards > > Vinod Joseph Professional Services - Service Provider Europe Juniper > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net > > > > -----Original Message----- From: Jakob Heitz > [mailto:jakob.heitz@ericsson.com] Sent: 12 June 2011 17:43 To: > stephane.litkowski@orange-ftgroup.com Cc: Vinod Joseph; > raszuk@cisco.com; idr@ietf.org; Thareja, Gaurav; Amit Khopkar; > Chintan.Shah@colt.net; laurent.lavallee@sns.bskyb.com Subject: Re: > [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection > > Has this been answered? > > -- Jakob Heitz. > > > On Jun 8, 2011, at 6:33 AM, > = "stephane.litkowski@orange-ftgroup.com" > wrote: > >> Thanks for the feedback. >> >> Regarding RTC behavior, I don't agree of your interpretation of the >> way it works, you said : "There is no best path calculation when >> using RT constrain. The RR just picks the number of paths that >> match a given RT and advertise this to the PE." Maybe I'm wrong, >> but I hope Robert will correct us as he is one of people who >> defined RTC :) For me, RTC doesn't change anything to the way BGP >> is globally working. RTC was designed to work for VPNs (first IPv4 >> but now it can be used for all VPN types). RTC is just a way to >> signal an interrest for a BGP speaker for a specific set of VPN >> prefixes matching some RTs (with end to end possibility to >> propagate it). This signalling will lead for the peer who received >> the RT NLRI to install a per peer ORF. And imo that's all. So if >> you take this case (VPN) : >> >> PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between >> them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. >> >> RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 >> -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 >> (IGP cost 5), LP100, ASPATH empty, RT2 >> >> RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, >> RT1 >> >> RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, >> RT1 >> >> RR1 still compute best path per VPN prefix (in your case it will be >> IPv4 but it doesn't really matter). RD1:X/Y label z -> Path2 is >> best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 >> will advertise these best path to the peers, especially PE1, but it >> has an ORF for PE1 which match only RT1, so only RD2:A/B and >> RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the >> community. >> >> >> What I mean by this, is that if you consider your case (IPv4), you >> will have this : >> >> PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked >> with RT1 and ASBR2 marked with RT2. PE1 will signal his interrested >> for RT1 and RT2. >> >> RR1 owns all IPv4 path from ASBRs, if we consider only one prefix >> X/Y received from all the ASBRs, we have this : X/Y Path 1 -> >> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=3DASBR2 >> (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=3DASBR3 (IGP cost >> c), LP 100, ASPATH c, RT3 ... Path x -> NH=3DASBRx (IGP cost x), LP >> 100, ASPATH x, RTx >> >> RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 >> peer. RR1 selects best path for all prefixes, and so for X/Y, it >> will choose one path, the best for him, based on his own criteria. >> So if it selects for example Path3 as best, no path will be >> exported to PE1 :( >> >> All, pls correct me if I'm wrong. >> >> >> Thanks, >> > From raszuk@cisco.com Sun Jun 12 11:57:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6624911E8118 for ; Sun, 12 Jun 2011 11:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.344 X-Spam-Level: X-Spam-Status: No, score=-8.344 tagged_above=-999 required=5 tests=[AWL=-1.924, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfULaEZFOCRv for ; Sun, 12 Jun 2011 11:57:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED8B11E8114 for ; Sun, 12 Jun 2011 11:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=8193; q=dns/txt; s=iport; t=1307905020; x=1309114620; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8+dQS3YKub5mPyDxE3zjxJqqIj5n469cyMlny7FBtkw=; b=HGzCPWPSDGmWTfTVGewbtFHZOCxZ75zqAjV1iFsM3FIBkIsLyWfnDU9G M1WtQZx9THzVtkmHtXcs9zOzF9YP+RZrzIFho7jzs/+1T/zvYq3ZiCcrn WmClUet/I0RCTN9WMXdyLbRcNiQOwq4nH0nA0ODHdFltEYVvqY4T/jpO0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHwK9U2rRDoI/2dsb2JhbABSpk93iHKiLIMODwGZZYYkBJE0hE+LEA X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="335397109" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2011 18:57:00 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5CIuvuT014850; Sun, 12 Jun 2011 18:56:57 GMT Message-ID: <4DF50BFA.1050905@cisco.com> Date: Sun, 12 Jun 2011 20:56:58 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 18:57:01 -0000 Vinod, That puts an interesting challenge to AF independent code which in most BGP implementations is BGP best path calculation. Moreover as each peer by design will signal different set of RTs you are essentially proposing a best path per peer. If I recall correctly even your add-path can not provide today different selection criteria on set of eligible paths for groups of peers. For one AF this should work very differently then for the other. Also it should work differently on RR then on ASBR. With this in mind I think we need to first wait to evaluate the new RTC draft then if that passes any further then IETF submission front end we could come back to discuss draft-vinod in it's -00 or -01 versions. Rgs, R. > When you explained how draft-vinod is to work I assumed and took as > obvious that you are calling for modification to how RTC works today for > AFI/SAFIs draft-vinod would be applicable for. > > Yes that's correct, we are calling for modification to the present RTC implementation. This was answered since when we were speaking about the RR specific RT, which can be signalled via RTC - In this case, the RR is to only announce the best path for a given prefix and this different to the present behaviour of RTC and will need to be modified. > > Someone asked if you are going to issue a new RTC spec to address this, > but that AFAIK was never answered. > > Yes that is correct. > > Regards > > Vinod Joseph > Professional Services - Service Provider Europe > Juniper Networks > M: +44 (0) 7500 835 876 > E: vjoseph@juniper.net > > > > > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: 12 June 2011 19:44 > To: Vinod Joseph > Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; laurent.lavallee@sns.bskyb.com > Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection > > Hi Vinod, > > Bruno interpretation is correct your is I am afraid wrong even to your > own implementation of RTC. > > RTC does not modify best path calculation. For VPN in the even there > would be overlapping VPNv4 nets different RD per VRF solves the problem > of different path with different RT being selected as overall best and > dropped by RTC. Perhaps operators may speak if they are using different > RDs in case there would be two different VPNv4 paths for the same net or > not today with RTC. > > When you explained how draft-vinod is to work I assumed and took as > obvious that you are calling for modification to how RTC works today for > AFI/SAFIs draft-vinod would be applicable for. > > Someone asked if you are going to issue a new RTC spec to address this, > but that AFAIK was never answered. > > > Let me also re-iterate that a BGP speaker does not need to have a > > "RT" configured, if it does not intend to add an extended community > > to any of its announced prefixes, but will have the ability to use RT > > constrain to indicate a list of RTs it is interested in. > > You contradicting yourself. In order to use RTC for signaling on the > interested set of RTs those I am afraid need to be configured. > > > words, only ASBRs may have Route Targets configured, and all PE may > > just use RTC to indicate preferences in a list of given ASBRs. > > RTC is not a cristal ball. When we wrote it we were thinking about > adding some magic to it, but since it would even further delay review > and release of the spec we concluded that we will leave it for later > time ;-). Perhaps the time is now ! > > Cheers, > R. > >> Yes it has been Jacob. >> >> The proposal uses ADD-PATH in combination with RTC - Therefore if a >> PE signals interest in a given RT (ASBRs), the RR will use ADD-PATH >> in order to make sure that NO best path calculation is used to >> tie-break between multiple paths within the same RT and in effect >> announce all or "N" paths (that can be configured on a per >> Peer/Peer-Group) basis to the PE. >> >> Let me also re-iterate that a BGP speaker does not need to have a >> "RT" configured, if it does not intend to add an extended community >> to any of its announced prefixes, but will have the ability to use RT >> constrain to indicate a list of RTs it is interested in. In other >> words, only ASBRs may have Route Targets configured, and all PE may >> just use RTC to indicate preferences in a list of given ASBRs. >> >> Regards >> >> Vinod Joseph Professional Services - Service Provider Europe Juniper >> Networks >> M: +44 (0) 7500 835 876 E: vjoseph@juniper.net >> >> >> >> -----Original Message----- From: Jakob Heitz >> [mailto:jakob.heitz@ericsson.com] Sent: 12 June 2011 17:43 To: >> stephane.litkowski@orange-ftgroup.com Cc: Vinod Joseph; >> raszuk@cisco.com; idr@ietf.org; Thareja, Gaurav; Amit Khopkar; >> Chintan.Shah@colt.net; laurent.lavallee@sns.bskyb.com Subject: Re: >> [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection >> >> Has this been answered? >> >> -- Jakob Heitz. >> >> >> On Jun 8, 2011, at 6:33 AM, >> "stephane.litkowski@orange-ftgroup.com" >> wrote: >> >>> Thanks for the feedback. >>> >>> Regarding RTC behavior, I don't agree of your interpretation of the >>> way it works, you said : "There is no best path calculation when >>> using RT constrain. The RR just picks the number of paths that >>> match a given RT and advertise this to the PE." Maybe I'm wrong, >>> but I hope Robert will correct us as he is one of people who >>> defined RTC :) For me, RTC doesn't change anything to the way BGP >>> is globally working. RTC was designed to work for VPNs (first IPv4 >>> but now it can be used for all VPN types). RTC is just a way to >>> signal an interrest for a BGP speaker for a specific set of VPN >>> prefixes matching some RTs (with end to end possibility to >>> propagate it). This signalling will lead for the peer who received >>> the RT NLRI to install a per peer ORF. And imo that's all. So if >>> you take this case (VPN) : >>> >>> PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between >>> them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. >>> >>> RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 >>> -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 >>> (IGP cost 5), LP100, ASPATH empty, RT2 >>> >>> RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, >>> RT1 >>> >>> RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, >>> RT1 >>> >>> RR1 still compute best path per VPN prefix (in your case it will be >>> IPv4 but it doesn't really matter). RD1:X/Y label z -> Path2 is >>> best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 >>> will advertise these best path to the peers, especially PE1, but it >>> has an ORF for PE1 which match only RT1, so only RD2:A/B and >>> RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the >>> community. >>> >>> >>> What I mean by this, is that if you consider your case (IPv4), you >>> will have this : >>> >>> PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked >>> with RT1 and ASBR2 marked with RT2. PE1 will signal his interrested >>> for RT1 and RT2. >>> >>> RR1 owns all IPv4 path from ASBRs, if we consider only one prefix >>> X/Y received from all the ASBRs, we have this : X/Y Path 1 -> >>> NH=ASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=ASBR2 >>> (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=ASBR3 (IGP cost >>> c), LP 100, ASPATH c, RT3 ... Path x -> NH=ASBRx (IGP cost x), LP >>> 100, ASPATH x, RTx >>> >>> RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 >>> peer. RR1 selects best path for all prefixes, and so for X/Y, it >>> will choose one path, the best for him, based on his own criteria. >>> So if it selects for example Path3 as best, no path will be >>> exported to PE1 :( >>> >>> All, pls correct me if I'm wrong. >>> >>> >>> Thanks, >>> >> > > From vjoseph@juniper.net Sun Jun 12 12:00:44 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294D311E811B for ; Sun, 12 Jun 2011 12:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.869 X-Spam-Level: X-Spam-Status: No, score=-3.869 tagged_above=-999 required=5 tests=[AWL=-1.449, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+Jgli8L-Q4v for ; Sun, 12 Jun 2011 12:00:43 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 0C50411E811E for ; Sun, 12 Jun 2011 12:00:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUMv3XcqRgKm+FyQA5pq+KNJLUFLiGL@postini.com; Sun, 12 Jun 2011 12:00:25 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 11:56:17 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 19:56:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 19:56:10 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE0D@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpMMIEX85ywh5hRQWQQ01SVrXRhgAAC3OQAAAjgsA= References: <5DD781A4BE13384A900438DF0608972C06996D07@emailemea4.jnpr.net> <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> From: Vinod Joseph To: Vinod Joseph , X-OriginalArrivalTime: 12 Jun 2011 18:56:14.0858 (UTC) FILETIME=[678206A0:01CC2932] Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:00:44 -0000 > Let me also re-iterate that a BGP speaker does not need to have a > = "RT" configured, if it does not intend to add an extended community > = to any of its announced prefixes, but will have the ability to use RT > = constrain to indicate a list of RTs it is interested in. You contradicting yourself. In order to use RTC for signaling on the = interested set of RTs those I am afraid need to be configured. Vinod# The proposed draft intends to permit the use of RT signalling via = RTC without the need for those specific RTs to be configured in every = BGP speaker. So yes RTC will be modified and can be used as a vehicle = for only signalling affinities or preferences in terms of RTs, also keep = in mind we are specifying the need for the RR to have the ability to = look at RTC prefixes announced by PEs and announce "ALL" or "N" number = of paths using ADD-PATH. Stay tuned for the next version. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Vinod Joseph=20 Sent: 12 June 2011 19:49 To: 'raszuk@cisco.com' Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: RE: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection When you explained how draft-vinod is to work I assumed and took as=20 obvious that you are calling for modification to how RTC works today for = AFI/SAFIs draft-vinod would be applicable for. Yes that's correct, we are calling for modification to the present RTC = implementation. This was answered since when we were speaking about the = RR specific RT, which can be signalled via RTC - In this case, the RR is = to only announce the best path for a given prefix and this different to = the present behaviour of RTC and will need to be modified. Someone asked if you are going to issue a new RTC spec to address this,=20 but that AFAIK was never answered. Yes that is correct.=20 Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 19:44 To: Vinod Joseph Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection Hi Vinod, Bruno interpretation is correct your is I am afraid wrong even to your=20 own implementation of RTC. RTC does not modify best path calculation. For VPN in the even there=20 would be overlapping VPNv4 nets different RD per VRF solves the problem=20 of different path with different RT being selected as overall best and=20 dropped by RTC. Perhaps operators may speak if they are using different=20 RDs in case there would be two different VPNv4 paths for the same net or = not today with RTC. When you explained how draft-vinod is to work I assumed and took as=20 obvious that you are calling for modification to how RTC works today for = AFI/SAFIs draft-vinod would be applicable for. Someone asked if you are going to issue a new RTC spec to address this,=20 but that AFAIK was never answered. > Let me also re-iterate that a BGP speaker does not need to have a > "RT" configured, if it does not intend to add an extended community > to any of its announced prefixes, but will have the ability to use RT > constrain to indicate a list of RTs it is interested in. You contradicting yourself. In order to use RTC for signaling on the=20 interested set of RTs those I am afraid need to be configured. > words, only ASBRs may have Route Targets configured, and all PE may > just use RTC to indicate preferences in a list of given ASBRs. RTC is not a cristal ball. When we wrote it we were thinking about=20 adding some magic to it, but since it would even further delay review=20 and release of the spec we concluded that we will leave it for later=20 time ;-). Perhaps the time is now ! Cheers, R. > Yes it has been Jacob. > > The proposal uses ADD-PATH in combination with RTC - Therefore if a > PE signals interest in a given RT (ASBRs), the RR will use ADD-PATH > in order to make sure that NO best path calculation is used to > tie-break between multiple paths within the same RT and in effect > announce all or "N" paths (that can be configured on a per > Peer/Peer-Group) basis to the PE. > > Let me also re-iterate that a BGP speaker does not need to have a > "RT" configured, if it does not intend to add an extended community > to any of its announced prefixes, but will have the ability to use RT > constrain to indicate a list of RTs it is interested in. In other > words, only ASBRs may have Route Targets configured, and all PE may > just use RTC to indicate preferences in a list of given ASBRs. > > Regards > > Vinod Joseph Professional Services - Service Provider Europe Juniper > Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net > > > > -----Original Message----- From: Jakob Heitz > [mailto:jakob.heitz@ericsson.com] Sent: 12 June 2011 17:43 To: > stephane.litkowski@orange-ftgroup.com Cc: Vinod Joseph; > raszuk@cisco.com; idr@ietf.org; Thareja, Gaurav; Amit Khopkar; > Chintan.Shah@colt.net; laurent.lavallee@sns.bskyb.com Subject: Re: > [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection > > Has this been answered? > > -- Jakob Heitz. > > > On Jun 8, 2011, at 6:33 AM, > = "stephane.litkowski@orange-ftgroup.com" > wrote: > >> Thanks for the feedback. >> >> Regarding RTC behavior, I don't agree of your interpretation of the >> way it works, you said : "There is no best path calculation when >> using RT constrain. The RR just picks the number of paths that >> match a given RT and advertise this to the PE." Maybe I'm wrong, >> but I hope Robert will correct us as he is one of people who >> defined RTC :) For me, RTC doesn't change anything to the way BGP >> is globally working. RTC was designed to work for VPNs (first IPv4 >> but now it can be used for all VPN types). RTC is just a way to >> signal an interrest for a BGP speaker for a specific set of VPN >> prefixes matching some RTs (with end to end possibility to >> propagate it). This signalling will lead for the peer who received >> the RT NLRI to install a per peer ORF. And imo that's all. So if >> you take this case (VPN) : >> >> PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between >> them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. >> >> RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 >> -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 >> (IGP cost 5), LP100, ASPATH empty, RT2 >> >> RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, >> RT1 >> >> RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, >> RT1 >> >> RR1 still compute best path per VPN prefix (in your case it will be >> IPv4 but it doesn't really matter). RD1:X/Y label z -> Path2 is >> best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 >> will advertise these best path to the peers, especially PE1, but it >> has an ORF for PE1 which match only RT1, so only RD2:A/B and >> RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the >> community. >> >> >> What I mean by this, is that if you consider your case (IPv4), you >> will have this : >> >> PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked >> with RT1 and ASBR2 marked with RT2. PE1 will signal his interrested >> for RT1 and RT2. >> >> RR1 owns all IPv4 path from ASBRs, if we consider only one prefix >> X/Y received from all the ASBRs, we have this : X/Y Path 1 -> >> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> NH=3DASBR2 >> (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=3DASBR3 (IGP cost >> c), LP 100, ASPATH c, RT3 ... Path x -> NH=3DASBRx (IGP cost x), LP >> 100, ASPATH x, RTx >> >> RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 >> peer. RR1 selects best path for all prefixes, and so for X/Y, it >> will choose one path, the best for him, based on his own criteria. >> So if it selects for example Path3 as best, no path will be >> exported to PE1 :( >> >> All, pls correct me if I'm wrong. >> >> >> Thanks, >> > From vjoseph@juniper.net Sun Jun 12 12:05:25 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F285511E811E for ; Sun, 12 Jun 2011 12:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.815 X-Spam-Level: X-Spam-Status: No, score=-3.815 tagged_above=-999 required=5 tests=[AWL=-1.395, BAYES_00=-2.599, FRT_INTEREST=3.579, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMmAQUZAxWXv for ; Sun, 12 Jun 2011 12:05:24 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBC211E8114 for ; Sun, 12 Jun 2011 12:05:16 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUN6YYxCeoQKXv/U+G77RpI2xyrjSgg@postini.com; Sun, 12 Jun 2011 12:05:23 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 12:04:04 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 20:04:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 20:03:57 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpMoWGsKVhGhwNTU2dLiRdff5VoAAAFtmg References: <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4D F50BFA.1 050905@cisco.com> From: Vinod Joseph To: X-OriginalArrivalTime: 12 Jun 2011 19:04:02.0735 (UTC) FILETIME=[7E6263F0:01CC2933] Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:05:25 -0000 Robert, Let me make this clear. The draft clearly specifies the need for = modification to RTC, since the RR is supposed to signal the best path - = ONLY in the case when a PE signal an RT that is RR specific. In other = words the PE wants a set of routes through RTs that it is interested in, = and the RR DOES NOT do any best path computation here and announces = paths via ADD-PATH as a vehicle. This has relevance only to IPV4 and = IPV6. The changes to the original RTC specification will be clearly addressed = in version 0.1. I do not want to get into a debate with you on whether = we should be having 2 drafts etc.=20 Version 0.1 will be submitted based on the feedback and views of the = many operators on this list. Thanks for your valuable comments as always ;-) Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 19:57 To: Vinod Joseph Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection Vinod, That puts an interesting challenge to AF independent code which in most=20 BGP implementations is BGP best path calculation. Moreover as each peer=20 by design will signal different set of RTs you are essentially proposing = a best path per peer. If I recall correctly even your add-path can not=20 provide today different selection criteria on set of eligible paths for=20 groups of peers. For one AF this should work very differently then for the other. Also it = should work differently on RR then on ASBR. With this in mind I think we need to first wait to evaluate the new RTC=20 draft then if that passes any further then IETF submission front end we=20 could come back to discuss draft-vinod in it's -00 or -01 versions. Rgs, R. > When you explained how draft-vinod is to work I assumed and took as > obvious that you are calling for modification to how RTC works today = for > AFI/SAFIs draft-vinod would be applicable for. > > Yes that's correct, we are calling for modification to the present RTC = implementation. This was answered since when we were speaking about the = RR specific RT, which can be signalled via RTC - In this case, the RR is = to only announce the best path for a given prefix and this different to = the present behaviour of RTC and will need to be modified. > > Someone asked if you are going to issue a new RTC spec to address = this, > but that AFAIK was never answered. > > Yes that is correct. > > Regards > > Vinod Joseph > Professional Services - Service Provider Europe > Juniper Networks > M: +44 (0) 7500 835 876 > E: vjoseph@juniper.net > > > > > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: 12 June 2011 19:44 > To: Vinod Joseph > Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com > Subject: Re: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection > > Hi Vinod, > > Bruno interpretation is correct your is I am afraid wrong even to your > own implementation of RTC. > > RTC does not modify best path calculation. For VPN in the even there > would be overlapping VPNv4 nets different RD per VRF solves the = problem > of different path with different RT being selected as overall best and > dropped by RTC. Perhaps operators may speak if they are using = different > RDs in case there would be two different VPNv4 paths for the same net = or > not today with RTC. > > When you explained how draft-vinod is to work I assumed and took as > obvious that you are calling for modification to how RTC works today = for > AFI/SAFIs draft-vinod would be applicable for. > > Someone asked if you are going to issue a new RTC spec to address = this, > but that AFAIK was never answered. > > > Let me also re-iterate that a BGP speaker does not need to have a > > "RT" configured, if it does not intend to add an extended = community > > to any of its announced prefixes, but will have the ability to = use RT > > constrain to indicate a list of RTs it is interested in. > > You contradicting yourself. In order to use RTC for signaling on the > interested set of RTs those I am afraid need to be configured. > > > words, only ASBRs may have Route Targets configured, and all PE = may > > just use RTC to indicate preferences in a list of given ASBRs. > > RTC is not a cristal ball. When we wrote it we were thinking about > adding some magic to it, but since it would even further delay review > and release of the spec we concluded that we will leave it for later > time ;-). Perhaps the time is now ! > > Cheers, > R. > >> Yes it has been Jacob. >> >> The proposal uses ADD-PATH in combination with RTC - Therefore if a >> PE signals interest in a given RT (ASBRs), the RR will use ADD-PATH >> in order to make sure that NO best path calculation is used to >> tie-break between multiple paths within the same RT and in effect >> announce all or "N" paths (that can be configured on a per >> Peer/Peer-Group) basis to the PE. >> >> Let me also re-iterate that a BGP speaker does not need to have a >> "RT" configured, if it does not intend to add an extended community >> to any of its announced prefixes, but will have the ability to use RT >> constrain to indicate a list of RTs it is interested in. In other >> words, only ASBRs may have Route Targets configured, and all PE may >> just use RTC to indicate preferences in a list of given ASBRs. >> >> Regards >> >> Vinod Joseph Professional Services - Service Provider Europe Juniper >> Networks >> M: +44 (0) 7500 835 876 E: vjoseph@juniper.net >> >> >> >> -----Original Message----- From: Jakob Heitz >> [mailto:jakob.heitz@ericsson.com] Sent: 12 June 2011 17:43 To: >> stephane.litkowski@orange-ftgroup.com Cc: Vinod Joseph; >> raszuk@cisco.com; idr@ietf.org; Thareja, Gaurav; Amit Khopkar; >> Chintan.Shah@colt.net; laurent.lavallee@sns.bskyb.com Subject: Re: >> [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection >> >> Has this been answered? >> >> -- Jakob Heitz. >> >> >> On Jun 8, 2011, at 6:33 AM, >> = "stephane.litkowski@orange-ftgroup.com" >> wrote: >> >>> Thanks for the feedback. >>> >>> Regarding RTC behavior, I don't agree of your interpretation of the >>> way it works, you said : "There is no best path calculation when >>> using RT constrain. The RR just picks the number of paths that >>> match a given RT and advertise this to the PE." Maybe I'm wrong, >>> but I hope Robert will correct us as he is one of people who >>> defined RTC :) For me, RTC doesn't change anything to the way BGP >>> is globally working. RTC was designed to work for VPNs (first IPv4 >>> but now it can be used for all VPN types). RTC is just a way to >>> signal an interrest for a BGP speaker for a specific set of VPN >>> prefixes matching some RTs (with end to end possibility to >>> propagate it). This signalling will lead for the peer who received >>> the RT NLRI to install a per peer ORF. And imo that's all. So if >>> you take this case (VPN) : >>> >>> PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between >>> them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1. >>> >>> RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1 >>> -> NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2 -> NH2 >>> (IGP cost 5), LP100, ASPATH empty, RT2 >>> >>> RD2:A/B label C Path 1 -> NH1 (IGP cost 10), LP100, ASPATH empty, >>> RT1 >>> >>> RD3:A/B label D Path 2 -> NH2 (IGP cost 5), LP100, ASPATH empty, >>> RT1 >>> >>> RR1 still compute best path per VPN prefix (in your case it will be >>> IPv4 but it doesn't really matter). RD1:X/Y label z -> Path2 is >>> best RD2:A/B label C -> Path1 RD3:A/B label D -> Path2 Then RR1 >>> will advertise these best path to the peers, especially PE1, but it >>> has an ORF for PE1 which match only RT1, so only RD2:A/B and >>> RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the >>> community. >>> >>> >>> What I mean by this, is that if you consider your case (IPv4), you >>> will have this : >>> >>> PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked >>> with RT1 and ASBR2 marked with RT2. PE1 will signal his interrested >>> for RT1 and RT2. >>> >>> RR1 owns all IPv4 path from ASBRs, if we consider only one prefix >>> X/Y received from all the ASBRs, we have this : X/Y Path 1 -> >>> NH=3DASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2 -> = NH=3DASBR2 >>> (IGP cost b), LP 100, ASPATH b, RT2 Path 3 -> NH=3DASBR3 (IGP = cost >>> c), LP 100, ASPATH c, RT3 ... Path x -> NH=3DASBRx (IGP cost x), = LP >>> 100, ASPATH x, RTx >>> >>> RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1 >>> peer. RR1 selects best path for all prefixes, and so for X/Y, it >>> will choose one path, the best for him, based on his own criteria. >>> So if it selects for example Path3 as best, no path will be >>> exported to PE1 :( >>> >>> All, pls correct me if I'm wrong. >>> >>> >>> Thanks, >>> >> > > From raszuk@cisco.com Sun Jun 12 12:05:29 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB5911E811E for ; Sun, 12 Jun 2011 12:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.38 X-Spam-Level: X-Spam-Status: No, score=-10.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO4FrktP9tyD for ; Sun, 12 Jun 2011 12:05:29 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9511E811B for ; Sun, 12 Jun 2011 12:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=583; q=dns/txt; s=iport; t=1307905528; x=1309115128; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZUSW8aRksqqTY+imK/BQlT3pLn/E64W8p7X1k2T5rUw=; b=g9IhPljAtP3ez7r8HbLzfuLVmxbFobufNHKCQPXhLu7Aq1GDNhAwNYn4 rkzrOyA8gQJ2CsfY2BFx9n4uj8+9WXxDQbzBS8VLHuLhW+LkD5x88ZiGq iEv4F+tNwWjGgaeIEV4O0ixlIwgdKuScFvBkqpNwK3U0Bcptflx8HcdAj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIMN9U2rRDoG/2dsb2JhbABSpk93iHKiJYMODwGZZYYkBJE0hE+LEA X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="375117835" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2011 19:05:28 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5CJ5QXX018345; Sun, 12 Jun 2011 19:05:26 GMT Message-ID: <4DF50DF7.7090909@cisco.com> Date: Sun, 12 Jun 2011 21:05:27 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0D@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE0D@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:05:29 -0000 Vinod, > Vinod# The proposed draft intends to permit the use of RT signalling > via RTC without the need for those specific RTs to be configured in > every BGP speaker. If RTC capability is exchanged and no RT is signaled default behaviour is not to send any routes towards such PE. Keep that in mind in your next version. > "ALL" or "N" number of paths using ADD-PATH. Are you also going to extend add-path spec to carry how many prefixes is required for given policy based exit PE ? If not how would the RR know how many paths to send to a given PE ? R. From vjoseph@juniper.net Sun Jun 12 12:06:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122C411E8114 for ; Sun, 12 Jun 2011 12:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47sE1eJ1fi3o for ; Sun, 12 Jun 2011 12:06:00 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 687F211E8124 for ; Sun, 12 Jun 2011 12:05:49 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUODNMuBeGWI5wGJ6Wu+V8aYqpcyEBm@postini.com; Sun, 12 Jun 2011 12:05:59 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 12:05:44 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 20:05:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC2933.B9FD1681" Date: Sun, 12 Jun 2011 20:05:36 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE0F@emailemea4.jnpr.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwnphKJUnElDOkmRcqWHutnhfgPOgBjZYYw References: <243870.49492.qm@web37903.mail.mud.yahoo.com> From: Vinod Joseph To: Reshmi Prem , Ilya Varlashkin X-OriginalArrivalTime: 12 Jun 2011 19:05:43.0250 (UTC) FILETIME=[BA4BC320:01CC2933] Cc: raszuk@cisco.com, gaurav.thareja@gmail.com, IETF IDR , Chintan.Shah@colt.net, bruno.decraene@orange-ftgroup.com Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:06:03 -0000 ------_=_NextPart_001_01CC2933.B9FD1681 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC2933.B9FD1681" ------_=_NextPart_002_01CC2933.B9FD1681 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Still waiting for inputs on this, Robert can you clarify this please? =20 Regards =20 Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E: vjoseph@juniper.net =20 =20 =20 =20 From: Reshmi Prem [mailto:reshmi_prem@yahoo.com]=20 Sent: 10 June 2011 20:39 To: Ilya Varlashkin Cc: raszuk@cisco.com Raszuk; Vinod Joseph; gaurav.thareja@gmail.com; bruno.decraene@orange-ftgroup.com; Chintan.Shah@colt.net; IETF IDR Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection =20 Illya: =20 ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As long as you don't do anything what other specification forbids, do you need to describe every possible combination of features that could be used together? Today you can use ADD-PATH to send multiple PATHs, tomorrow there will be another solution to do it. NH SAFI neither forbids nor requires you to use any other BGP feature beyond what's specified in the drafts, so by all means if you want multiple best PATHs from RR-client perspective you can combine NH SAFI with ADD-PATH. If you don't need multiple paths, you just don't use multiple paths. Do you feel this combination should be explicitly spelled in the NH SAFI specs? =20 >>>>>>>>>>>>>>> You are talking about using ADD-PATH to choose a select no. of paths based only on admin costs that are statically specified on the PE. This needs some work or integration or extension or whatever you call it, to ADD-PATH. You need to mention this in your draft. =20 ok, implicit assumption is that RR will use a) cost provided by RR-c; b) if RR-c cost is unavailable for whatever reason RR will use its own cost. Note that original idea is that RR-c informs RR about all costs. If network policies call for non-IGP preference, then RR-c can use ever-increasing numbers calculated in a way operator prefers. First N (number of preferred exits) can be explicitly configured on RR-c, the rest RR-c will calculate itself by ordering IGP costs of remaining exits. To give an example: a PE prefers NH5 and NH9, which operator configures on the PE manually. Let's say at some moment _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following info to RR: first it tells that NH5:cost1, NH9:cost2 (because it configured by operator), then PE takes remaining next-hops and arranges them in order of increasing IGP cost behind first two next-hops, the cost reported for NH-i to RR is the position of that NH-i in the just created list. When IGP cost to non-preferred next-hops changes (due to topology change), PE just re-evaluates NH order and sends updated cost to RR. When preferred ASBR's are not available as feasible path to certain prefix, RR just uses whatever is next NH in the list received from RR-c but only for prefixes where preferred ASBR is not feasible exit. When preferred ASBR's fail (i.e. no path can be reached via them), RR uses for whatever is next NH in the list received from RR-c for all prefixes. So in general, when certain prefix cannot be reached via preferred ASBR's (regardless of the reason) then RR uses next NH in the list received from RR-c. If for some reason connectivity from RR-c to ASBR fails, RR-c will inform RR that particular NH is no longer feasible (as described in NH SAFI draft) and RR will stop considering that ASBR when calculating routes for given RR-c (even if from RR perspective or from any other router perspective that very same ASBR is still reachable). Same question as above - do you feel such behaviour should be explicitly spelled out even though it's natural? =20 >>>>>>>>>>>>>>>>I am lost sorry. Simple example: network has 10 ASBRs. PE1 says ASBR1=3DMETRIC15 and ASBR2=3DMETRIC20 and sends this info to = the RR. Now RR reflects both these ASBR paths to PE1 with the same metrics? =20 >>>>>>>>>>>>>>>>>>>>PE1 automatically calculates IGP Cost to ASBR 3--10? >>>>>>>>>>>>>>>>>>>>>>> Assume ASBR 3-10 have metrics as follows ASBR3=3D3, ASBR4=3D4 .....ASBR10=3D10, This can happen right?=20 =20 >>>>>>>>>>>>>>>>>>>>>>>>>> RR advertises ASBR 3 TO ASBR 10 paths to PE1? =20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does RR ensure that non candidate (preferred paths) are not announced to the PE upfront? =20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How do you ensure that non candidate paths always have a higher metric than candidate paths? =20 - Prem --- On Fri, 6/10/11, Ilya Varlashkin wrote: =09 From: Ilya Varlashkin Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection To: "Reshmi Prem" Cc: "raszuk@cisco.com Raszuk" , "Vinod Joseph" , gaurav.thareja@gmail.com, bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, "IETF IDR" Date: Friday, June 10, 2011, 2:04 PM On Jun 10, 2011, at 19:21 , Reshmi Prem wrote: =09 > Ilya, > =20 > I did not see your draft specifying that you would be using ADD-PATH, Can you confirm this? >=20 =09 ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As long as you don't do anything what other specification forbids, do you need to describe every possible combination of features that could be used together? Today you can use ADD-PATH to send multiple PATHs, tomorrow there will be another solution to do it. NH SAFI neither forbids nor requires you to use any other BGP feature beyond what's specified in the drafts, so by all means if you want multiple best PATHs from RR-client perspective you can combine NH SAFI with ADD-PATH. If you don't need multiple paths, you just don't use multiple paths. Do you feel this combination should be explicitly spelled in the NH SAFI specs? =09 > Vinod's draft specifies a means of using an RR specific RT to permit a RR calculated best path in addition to RTC specified paths. How does your draft handle this? What happens if the list of ASBRS that i indicate a metric for disappear?? =09 ok, implicit assumption is that RR will use a) cost provided by RR-c; b) if RR-c cost is unavailable for whatever reason RR will use its own cost. Note that original idea is that RR-c informs RR about all costs. If network policies call for non-IGP preference, then RR-c can use ever-increasing numbers calculated in a way operator prefers. First N (number of preferred exits) can be explicitly configured on RR-c, the rest RR-c will calculate itself by ordering IGP costs of remaining exits. To give an example: a PE prefers NH5 and NH9, which operator configures on the PE manually. Let's say at some moment _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following info to RR: first it tells that NH5:cost1, NH9:cost2 (because it configured by operator), then PE takes remaining next-hops and arranges them in order of increasing IGP cost behind first two next-hops, the cost reported for NH-i to RR is the position of that NH-i in the just created list. When IGP cost to non-preferred next-hops changes (due to topology change), PE just re-evaluates NH order and sends updated cost to RR. When preferred ASBR's are not available as feasible path to certain prefix, RR just uses whatever is next NH in the list received from RR-c but only for prefixes where preferred ASBR is not feasible exit. When preferred ASBR's fail (i.e. no path can be reached via them), RR uses for whatever is next NH in the list received from RR-c for all prefixes. So in general, when certain prefix cannot be reached via preferred ASBR's (regardless of the reason) then RR uses next NH in the list received from RR-c. If for some reason connectivity from RR-c to ASBR fails, RR-c will inform RR that particular NH is no longer feasible (as described in NH SAFI draft) and RR will stop considering that ASBR when calculating routes for given RR-c (even if from RR perspective or from any other router perspective that very same ASBR is still reachable). Same question as above - do you feel such behaviour should be explicitly spelled out even though it's natural? =09 Kind regards, iLya =20 ------_=_NextPart_002_01CC2933.B9FD1681 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Still waiting for inputs on this, Robert can you clarify this = please?

 

Regards

 

Vinod Joseph

Professional Services – Service Provider Europe

Juniper = Networks           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;       

M: +44 (0) 7500 835 876

E: vjoseph@juniper.net

 

 

  

 


From:= Reshmi = Prem [mailto:reshmi_prem@yahoo.com]
Sent: 10 June 2011 = 20:39
To: Ilya Varlashkin
Cc: raszuk@cisco.com = Raszuk; Vinod Joseph; gaurav.thareja@gmail.com; = bruno.decraene@orange-ftgroup.com; Chintan.Shah@colt.net; IETF = IDR
Subject: Re: [Idr] = draft-vinod-lavallee-bgp-optimal-route-reflection

 

Illya:

 

ehrm...use of ADD-PATH is not feature of NH SAFI, but = of...ADD-PATH. As long as you don't do anything what other specification = forbids, do you need to describe every possible combination of features = that could be used together? Today you can use ADD-PATH to send multiple = PATHs, tomorrow there will be another solution to do it. NH SAFI neither = forbids nor requires you to use any other BGP feature beyond what's = specified in the drafts, so by all means if you want multiple best PATHs = from RR-client perspective you can combine NH SAFI with ADD-PATH. If you = don't need multiple paths, you just don't use multiple paths. Do you = feel this combination should be explicitly spelled in the NH SAFI = specs?

 

>>>>>>>>>>>>>>= ;> You are talking about using ADD-PATH to choose a select no. of = paths based only on admin costs that are statically specified on the PE. = This needs some work or integration or extension or whatever you call = it, to ADD-PATH. You need to mention this in your = draft.

 

ok, implicit assumption is that RR will use a) cost = provided by RR-c; b) if RR-c cost is unavailable for whatever reason RR = will use its own cost. Note that original idea is that RR-c informs RR = about all costs. If network policies call for non-IGP preference, then = RR-c can use ever-increasing numbers calculated in a way operator = prefers. First N (number of preferred exits) can be explicitly = configured on RR-c, the rest RR-c will calculate itself by ordering IGP = costs of remaining exits. To give an example: a PE prefers NH5 and NH9, = which operator configures on the PE manually. Let's say at some moment = _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH50. PE = sends following info to RR: first it tells that NH5:cost1, NH9:cost2 = (because it configured by operator), then PE takes remaining next-hops = and arranges them in order of increasing IGP cost behind first two = next-hops, the cost reported for NH-i to RR is the position of that NH-i = in the just created list. When IGP cost to non-preferred next-hops = changes (due to topology change), PE just re-evaluates NH order and = sends updated cost to RR. When preferred ASBR's are not available as = feasible path to certain prefix, RR just uses whatever is next NH in the = list received from RR-c but only for prefixes where preferred ASBR is = not feasible exit. When preferred ASBR's fail (i.e. no path can be = reached via them), RR uses for whatever is next NH in the list received = from RR-c for all prefixes. So in general, when certain prefix cannot be = reached via preferred ASBR's (regardless of the reason) then RR uses = next NH in the list received from RR-c. If for some reason connectivity = from RR-c to ASBR fails, RR-c will inform RR that particular NH is no = longer feasible (as described in NH SAFI draft) and RR will stop = considering that ASBR when calculating routes for given RR-c (even if = from RR perspective or from any other router perspective that very same = ASBR is still reachable). Same question as above - do you feel such = behaviour should be explicitly spelled out even though it's = natural?

 

>>>>>>>>>>>>>>= ;>>I am lost sorry. Simple example: network has 10 ASBRs. PE1 says = ASBR1=3DMETRIC15 and ASBR2=3DMETRIC20 and sends this info to the RR. Now = RR reflects both these ASBR paths to PE1 with the same = metrics?

 

>>>>>>>>>>>>>>= ;>>>>>>PE1 automatically calculates IGP Cost to ASBR = 3--10?

>>>>>>>>>>>>>>= ;>>>>>>>>> Assume ASBR 3-10 have metrics as = follows ASBR3=3D3, ASBR4=3D4 .....ASBR10=3D10, This can happen right? =

 

>>>>>>>>>>>>>>= ;>>>>>>>>>>>> RR advertises ASBR 3 = TO ASBR 10 paths to PE1?

 

>>>>>>>>>>>>>>= ;>>>>>>>>>>>>>>>>> = How does RR ensure that non candidate (preferred paths) are not = announced to the PE upfront?

 

>>>>>>>>>>>>>>= ;>>>>>>>>>>>>>>>>>>= How do you ensure that non candidate paths always have a higher metric = than candidate paths?

 

- = Prem

--- On Fri, 6/10/11, Ilya Varlashkin = <ilya@nobulus.com> = wrote:


From: Ilya = Varlashkin <ilya@nobulus.com>
Subject: Re: [Idr] = draft-vinod-lavallee-bgp-optimal-route-reflection
To: "Reshmi = Prem" <reshmi_prem@yahoo.com>
Cc: "raszuk@cisco.com = Raszuk" <raszuk@cisco.com>, "Vinod Joseph" = <vjoseph@juniper.net>, gaurav.thareja@gmail.com, = bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, "IETF = IDR" <idr@ietf.org>
Date: Friday, June 10, 2011, 2:04 = PM

On Jun 10, 2011, at 19:21 , Reshmi Prem = wrote:

> Ilya,
> 
> I did not see your draft = specifying that you would be using ADD-PATH, Can you confirm = this?
>

ehrm...use of ADD-PATH is not feature of NH SAFI, = but of...ADD-PATH. As long as you don't do anything what other = specification forbids, do you need to describe every possible = combination of features that could be used together? Today you can use = ADD-PATH to send multiple PATHs, tomorrow there will be another solution = to do it. NH SAFI neither forbids nor requires you to use any other BGP = feature beyond what's specified in the drafts, so by all means if you = want multiple best PATHs from RR-client perspective you can combine NH = SAFI with ADD-PATH. If you don't need multiple paths, you just don't use = multiple paths. Do you feel this combination should be explicitly = spelled in the NH SAFI specs?

> Vinod's draft specifies a = means of using an RR specific RT to permit a RR calculated best path in = addition to RTC specified paths. How does your draft handle this? What = happens if the list of ASBRS that i indicate a metric for = disappear??

ok, implicit assumption is that RR will use a) cost = provided by RR-c; b) if RR-c cost is unavailable for whatever reason RR = will use its own cost. Note that original idea is that RR-c informs RR = about all costs. If network policies call for non-IGP preference, then = RR-c can use ever-increasing numbers calculated in a way operator = prefers. First N (number of preferred exits) can be explicitly = configured on RR-c, the rest RR-c will calculate itself by ordering IGP = costs of remaining exits. To give an example: a PE prefers NH5 and NH9, = which operator configures on the PE manually. Let's say at some moment = _all_ prefixes are reachable via set of next-hops NH1,NH2,...,NH50. PE = sends following info to RR: first it tells that NH5:cost1, NH9:cost2 = (because it configured by operator), then PE takes remaining next-hops = and arranges them in order of increasing IGP cost behind first two = next-hops, the cost reported for NH-i to RR is the position of that NH-i = in the just created list. When IGP cost to non-preferred next-hops = changes (due to topology change), PE just re-evaluates NH order and = sends updated cost to RR. When preferred ASBR's are not available as = feasible path to certain prefix, RR just uses whatever is next NH in the = list received from RR-c but only for prefixes where preferred ASBR is = not feasible exit. When preferred ASBR's fail (i.e. no path can be = reached via them), RR uses for whatever is next NH in the list received = from RR-c for all prefixes. So in general, when certain prefix cannot be = reached via preferred ASBR's (regardless of the reason) then RR uses = next NH in the list received from RR-c. If for some reason connectivity = from RR-c to ASBR fails, RR-c will inform RR that particular NH is no = longer feasible (as described in NH SAFI draft) and RR will stop = considering that ASBR when calculating routes for given RR-c (even if = from RR perspective or from any other router perspective that very same = ASBR is still reachable). Same question as above - do you feel such = behaviour should be explicitly spelled out even though it's = natural?

Kind = regards,
iLya

 =

------_=_NextPart_002_01CC2933.B9FD1681-- ------_=_NextPart_001_01CC2933.B9FD1681 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhhQAmAPf/AOzw82NjY8zMzMbGxjg4OBQUFJiYmM/X35aWltPT05mqu7KyssnJyXh4eO/v 73Z2dubr7+Tk5Pr7/Lm5ueHh4YCAgH5+ftjY2LCwsA0NDTU1NaysrKi3xc7Ozvv8/aampvb4+aCw wFBQUO/y9TY2Ni4uLlhYWAICAlZWVtDY4MfQ2iEhIV5eXoSEhJ6enpqamtvb27C9yykpKcrT3Ke2 xMjR2srKyvDz9oeHh729vUxMTEFBQVxcXGpqaoKCglpaWqa1xNXc40lJSWVlZSUlJWBgYEpKSsLN 1hkZGb/K1KGhobnF0HFxcZycnD4+PhAQEKKywZ+vv4uLi05OTuXp7R0dHdPa4TIyMsTN17vG0rjE zzw8PB4eHhISEicnJwgICCIiIvv7+9TU1JGRkZCQkPj4+NHR0fDw8LW1tevr621tbZSUlI2NjXV1 dURERFRUVPPz8/39/ejo6P7+/qWlpcPDw/n6+29vb4iIiOzs7Pb29urq6vr6+rK/zOfn57fDz+Pj 47TAzbXBzdzi6EVFRfj5+qSzwvHx8fn5+b3I0/Dy9bG+y/L09vT2+JOTk/z9/dLZ4fP19/X19fDz 9e3t7TAwMNvh5/z8/I+Pj6SkpLO/zKW0w/L095KSksnS27rG0aq4xvLy8nNzc6mpqcLCwoyMjNbW 1qy6yPz8/VVVVW5ubqioqI6Ojq68ya+8ycTO2NXV1dDQ0K67yc3V3ert8a27yKy6x8bP2cHBwfj5 +/H09v39/vL19+7x9NTb4nx8fL6+vlNTU6urqzo6OrbCzrbDz5WVlUdHR+bm5uLi4mhoaK27yeDl 6ru7u3R0dPr7+8zV3cXO2OLn683V3s3W3oebsNrg5srT27XCztPb4pytvuzv8rzH0vHz9ujr76u4 x6Ojo93j6e3w866ursDL1bPAzN/f36GxwNbd5N/k6re3t97j6enp6bbCz+vu8rTBza+9yejs8LS0 tK26yJeoueHm693j6Nzc3K+8yqq5xpqrvKu5x/X2+PX3+AAAAP///yH5BAEAAP8ALAAAAACFACYA AAj/AP8JHEiwoMGDCBMqXMiwocOHEA3yAQSIj8A4yADBeZgG0BmEeQYowSPqDpMWLnD5SUhpj56B evakmUmTpsxQcR6aWmWBhQgRAUpNoNQwArAmLZjccbZAYYIMGUwJPLQig4GHOjL8MmjDRAF/YMOG faIDjcEwGp5cFWigS5cncOPKRVLCRCaLCV8QOCFWLJIechIuEJKhrz8hCmOBTSDwzBN/nR7u8Ceq oIEvYDOU0MEigM8rj8E6yzkwzAp/rAZiMsw6LIEOByMcA3uiEo8GLSrc0YEELBgBBuM0CNuFhIgi AXiwUWjG3wkxjb+ueejGXxuCwMA+wUPhILIXXMDi/yEYhog/MgPH+JNRp71796QWNJABtgBjgntK gGVxv6ADMo9xsUdB6vmzgguBPdTcc9H5M51D1V0n0CVO+IMELAv5QYA/TyT4T3nnpecPAQwhggdY TpAmkAjOrbIQA4UVQdAhvRGwUkQLQvfPGdJRZ91Aivmz1kIC8BWZQCCiJ5B6GjjUBlgMDIQLWEMq dGIGEQy0gHMDRCRQjg0+2FCEA7ngTwY3MqSBPyiUZp6S/zDpUBqP4TCQCSM6dMhXmQykij8lePml czry6KCPEv5TgT+VzOFQAP4M42aIS/rTpEMVmiCQHI+98NBsdwzE4huC/gPmjj1C+KNAd/hjxEOL yv/g6IdvinhpQzz444RAzTgHw0Ot6jDQZMqUeqqhYjJEpkDK+BPMQ6X4AwZeSdr6EAu6CuTIemE8 JEWeAm2ohrGEhonoQJCS6hAbBpaBZK2V3sqQEP6kItBwIkCUyXqXhOvPuIIem+qYq/6T7kPsruAu rZTGaalDZYTng0CQ7oDGxRhnrDEaD/hDxMLikssgqoeqmujB67b7bsNyNrQKWKQIhGdrNIOFxEv/ hBxwuSQnu9CyBvujbkMJL1xtpSQ0xEBvJSAiEAr+FKDB1FRXbTXVU4D8r8iFDqxswSgTrTLDcKp3 BRxop612GgJUUNgJEwz0gz89lOovwF4KXDLBJwv/jfDYRzv8RRWEF254F2FlsAFBQ/jDgt05b73z yHvu/XXfQzNU9Mpl1xzWCSv0oONAwwlrt8558xxKb8Y8RIg/D6Drd8oKcy4iGHTkrvvu8piCc0Hb eoGXoKjjyLMep42HqT8WyJ75QpuTLSKJgvZ6AoalFg/RqXHop4pDfJiHifN/1y59vKVy6o8jp0ue +sj/0LtrQzDwNQ75tBsNr8PyRoRno9lzn/GuNxAc+OMLo1NIC5xzD/yJzXyBa5mgSAEWOznEAQTR 3kM64JwLDCQZhXGChxAygMeYjmKze6D+WPYwu6UCLEdSCAVQcIU8DAR1l2BHt5R2QHMQZFH+4IIL /wBxlgv8AjMnAI4DNQe4/UlQUA4gAVgIkYONFOQSsGhAaEZxQ8mFYQFKEIbTGCIMf3TBhqURReJK IAQTmCAVbvACX6LmIoIUwR/5csi3qmC006RGIKu5AuT+kYdcgaUKhCiCKu4wBB3QByzDUIeKpFg3 Qm4AAR9Ik0KYwC2DTEAEX2kNF4bwq4Ko4QmPc8ganlACo4FmSAZ4wg4GKZBPhtIwXdDBKFQkEEI8 IXb/QMQCFrCB3yVEEuHRFEL2MIAPYCI3LXDEBjpgRYMcQg4fcYgk5JCGWf0jDXKQxEC2SRRaCiQk mWBFBSpQCnDUIQ0IoYQcQjEQRFDAmAgpA6T8kf8Dc/rznwAVVBiSMYoNOSug5szFQOagUA/w4gaK UMQuGjECXURCEZNAhR0G4oFZzWGj/2AEBMTBUV5gFKQSeMRFQCAQcUCAEw35ASG2IAPMgEUE2USo 3XahgBQIpB+u+Ac1zrGMWriCH7eYhyEU0IpWjIAYjRAIDXwhkANYYQ6aAMIfarGJEfxjFufoQwwM YYV/JMIS/yjEKSDwCLFygwavYMgc66ODD+iUlmGIwjlo8Y9GAOEf0aBqQQaxiIEkIgghpQcxBGIL XdTgDyr9ByRO8Y9XQEMg3aDBP/5gjX9oArFUkIVA5hDVhRgDDwjAgADQeNdB2uEUgzDEI0Cg2Rr/ 1GAEI1DErAbRh4GkAx//SMEMBGGHXoDiH6BgBEFsAYIaHEAgEtDsEiyxCE8IZBIhQEcvvNna7hrE Dn+dQRLiwIF/eMIQWvhDFgohEN4ORAKGsEM7IoEFZkBiBv/gAHsHUg4AQCMEf9AEKKjxD25oIwaf GEg8yCGIfODXuxAeCHif8Y9lQCOoKkDsYHtr2FsUlhmJ+AQA/vGNSRBkH4XwxCeksYRiCKQYgfjH OyBREEZAga8RhrAdDMFeTuhDG4ClcUEsAQ+CUKEa1/iHB/Sh2X/UQBASqGorKjuLf6BiE9v4BzY6 G4kodCMS7rgIB7yRYwhLIBAU/oc9NAsJDgTiN83dEEg9EkGQK5P0H0u4xUWSIAtBLGIRMJ1GNgSy Diz84wjhEIglXiGOPgjiDzFQQZknTWlaBgQAOw== ------_=_NextPart_001_01CC2933.B9FD1681-- From raszuk@cisco.com Sun Jun 12 12:09:27 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982E111E811E for ; Sun, 12 Jun 2011 12:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.386 X-Spam-Level: X-Spam-Status: No, score=-10.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p6GdS43y8rk for ; Sun, 12 Jun 2011 12:09:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD5811E8114 for ; Sun, 12 Jun 2011 12:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=194; q=dns/txt; s=iport; t=1307905767; x=1309115367; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JwmH9K/j6WTtbH4TQ/C+jlhrwxd0oOaI1NQ5DmT/lp8=; b=Y7MSS32ERH8N+GPRZNS9j/gF3IPrNA6yBzmf/iUgB8n7+bM4aRYYhsbq LD/bdom05GjHy0opefqv7qX5iX67/fet8UrCDRtq5b4dtz02hkfUBAUBs PCkPbej+uHcPC8+aAO+dXgs0XSWX+8RXOQKLHngJC5/dYZ0OVrqS/jJpw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK4O9U2rRDoJ/2dsb2JhbABSpk93iHKiDYMODwGZZYYkBJE0hE+LEA X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="375118308" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2011 19:09:13 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5CJ9A07020983; Sun, 12 Jun 2011 19:09:11 GMT Message-ID: <4DF50ED7.6040005@cisco.com> Date: Sun, 12 Jun 2011 21:09:11 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:09:27 -0000 > Version 0.1 will be submitted based on the feedback and views of the > many operators on this list. Could you summarize those inputs from many operators on this list ? Many thx, R. From vjoseph@juniper.net Sun Jun 12 12:10:30 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2B211E8118 for ; Sun, 12 Jun 2011 12:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkkawJpGnWvR for ; Sun, 12 Jun 2011 12:10:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id B0C6611E8125 for ; Sun, 12 Jun 2011 12:10:21 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUPFUhWqpffm3ogvNdqFh1vnxPvC54q@postini.com; Sun, 12 Jun 2011 12:10:29 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 12:10:12 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 20:10:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 20:10:08 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE12@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpNEH0GnuSPZeqRsGp4bhXFfRu8gAAA+IQ References: <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> <4DF50ED7.6040005@c isco.com > From: Vinod Joseph To: X-OriginalArrivalTime: 12 Jun 2011 19:10:10.0950 (UTC) FILETIME=[59DB8A60:01CC2934] Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:10:30 -0000 Version 0.1 shortly! Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 20:09 To: Vinod Joseph Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection > Version 0.1 will be submitted based on the feedback and views of the > many operators on this list. Could you summarize those inputs from many operators on this list ? Many thx, R. From raszuk@cisco.com Sun Jun 12 12:10:52 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FF011E8124 for ; Sun, 12 Jun 2011 12:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbjDHQvBxNw3 for ; Sun, 12 Jun 2011 12:10:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id BBD5011E8123 for ; Sun, 12 Jun 2011 12:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=8961; q=dns/txt; s=iport; t=1307905851; x=1309115451; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fNWA3HliRQU6RSLMScjtgeaQv3gpkceXBsH+06K0WxU=; b=EQgeETMm+0HbN0HcsGastsS4MpeFp4KUpPF+JYYg/71ldC2cd3jKqgP0 JgFVOJXNiqcYKyV3upo/ZGIevgBuiKLI9h5ggSw0ez2WnI6pEfY/oo/tv Xk21x/6Nds9qRhjke9mvqYVCNRIN0l/TRgKGT9cIoW2Bt18nl1uRmcuJt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgBAK4O9U2rRDoH/2dsb2JhbABSl1cPjml3iHKiDYMODwGZZYYkBJE0hE+EQIZQ X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="375118511" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2011 19:10:51 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5CJAmMR003619; Sun, 12 Jun 2011 19:10:49 GMT Message-ID: <4DF50F39.3070509@cisco.com> Date: Sun, 12 Jun 2011 21:10:49 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <243870.49492.qm@web37903.mail.mud.yahoo.com> <5DD781A4BE13384A900438DF0608972C06A1FE0F@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE0F@emailemea4.jnpr.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF IDR , bruno.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, Chintan.Shah@colt.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:10:52 -0000 Vinod, I would like to clarify however the questions are so embedded that they are hard to understand. Perhaps author of them could restate them more clearly. Thx, R. > Still waiting for inputs on this, Robert can you clarify this please? > > Regards > > *Vinod Joseph*** > > Professional Services – Service Provider Europe > > Juniper Networks > > M: +44 (0) 7500 835 876 > > E:vjoseph@juniper.net > > cid:image003.gif@01CA5909.95D8EDC0 > > > *From:*Reshmi Prem [mailto:reshmi_prem@yahoo.com] > *Sent:* 10 June 2011 20:39 > *To:* Ilya Varlashkin > *Cc:* raszuk@cisco.com Raszuk; Vinod Joseph; gaurav.thareja@gmail.com; > bruno.decraene@orange-ftgroup.com; Chintan.Shah@colt.net; IETF IDR > *Subject:* Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection > > Illya: > > ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As > long as you don't do anything what other specification forbids, do you > need to describe every possible combination of features that could be > used together? Today you can use ADD-PATH to send multiple PATHs, > tomorrow there will be another solution to do it. NH SAFI neither > forbids nor requires you to use any other BGP feature beyond what's > specified in the drafts, so by all means if you want multiple best PATHs > from RR-client perspective you can combine NH SAFI with ADD-PATH. If you > don't need multiple paths, you just don't use multiple paths. Do you > feel this combination should be explicitly spelled in the NH SAFI specs? > > >>>>>>>>>>>>>>> You are talking about using ADD-PATH to choose a select > no. of paths based only on admin costs that are statically specified on > the PE. This needs some work or integration or extension or whatever you > call it, to ADD-PATH. You need to mention this in your draft. > > ok, implicit assumption is that RR will use a) cost provided by RR-c; b) > if RR-c cost is unavailable for whatever reason RR will use its own > cost. Note that original idea is that RR-c informs RR about all costs. > If network policies call for non-IGP preference, then RR-c can use > ever-increasing numbers calculated in a way operator prefers. First N > (number of preferred exits) can be explicitly configured on RR-c, the > rest RR-c will calculate itself by ordering IGP costs of remaining > exits. To give an example: a PE prefers NH5 and NH9, which operator > configures on the PE manually. Let's say at some moment _all_ prefixes > are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following > info to RR: first it tells that NH5:cost1, NH9:cost2 (because it > configured by operator), then PE takes remaining next-hops and arranges > them in order of increasing IGP cost behind first two next-hops, the > cost reported for NH-i to RR is the position of that NH-i in the just > created list. When IGP cost to non-preferred next-hops changes (due to > topology change), PE just re-evaluates NH order and sends updated cost > to RR. When preferred ASBR's are not available as feasible path to > certain prefix, RR just uses whatever is next NH in the list received > from RR-c but only for prefixes where preferred ASBR is not feasible > exit. When preferred ASBR's fail (i.e. no path can be reached via them), > RR uses for whatever is next NH in the list received from RR-c for all > prefixes. So in general, when certain prefix cannot be reached via > preferred ASBR's (regardless of the reason) then RR uses next NH in the > list received from RR-c. If for some reason connectivity from RR-c to > ASBR fails, RR-c will inform RR that particular NH is no longer feasible > (as described in NH SAFI draft) and RR will stop considering that ASBR > when calculating routes for given RR-c (even if from RR perspective or > from any other router perspective that very same ASBR is still > reachable). Same question as above - do you feel such behaviour should > be explicitly spelled out even though it's natural? > > >>>>>>>>>>>>>>>>I am lost sorry. Simple example: network has 10 ASBRs. > PE1 says ASBR1=METRIC15 and ASBR2=METRIC20 and sends this info to the > RR. Now RR reflects both these ASBR paths to PE1 with the same metrics? > > >>>>>>>>>>>>>>>>>>>>PE1 automatically calculates IGP Cost to ASBR 3--10? > > >>>>>>>>>>>>>>>>>>>>>>> Assume ASBR 3-10 have metrics as follows > ASBR3=3, ASBR4=4 .....ASBR10=10, This can happen right? > > >>>>>>>>>>>>>>>>>>>>>>>>>> RR advertises ASBR 3 TO ASBR 10 paths to PE1? > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does RR ensure that non candidate > (preferred paths) are not announced to the PE upfront? > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How do you ensure that non candidate > paths always have a higher metric than candidate paths? > > - Prem > > --- On *Fri, 6/10/11, Ilya Varlashkin //* wrote: > > > From: Ilya Varlashkin > Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection > To: "Reshmi Prem" > Cc: "raszuk@cisco.com Raszuk" , "Vinod Joseph" > , gaurav.thareja@gmail.com, > bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, "IETF IDR" > > Date: Friday, June 10, 2011, 2:04 PM > > On Jun 10, 2011, at 19:21 , Reshmi Prem wrote: > > > Ilya, > > > > I did not see your draft specifying that you would be using > ADD-PATH, Can you confirm this? > > > > ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. > As long as you don't do anything what other specification forbids, > do you need to describe every possible combination of features that > could be used together? Today you can use ADD-PATH to send multiple > PATHs, tomorrow there will be another solution to do it. NH SAFI > neither forbids nor requires you to use any other BGP feature beyond > what's specified in the drafts, so by all means if you want multiple > best PATHs from RR-client perspective you can combine NH SAFI with > ADD-PATH. If you don't need multiple paths, you just don't use > multiple paths. Do you feel this combination should be explicitly > spelled in the NH SAFI specs? > > > Vinod's draft specifies a means of using an RR specific RT to > permit a RR calculated best path in addition to RTC specified paths. > How does your draft handle this? What happens if the list of ASBRS > that i indicate a metric for disappear?? > > ok, implicit assumption is that RR will use a) cost provided by > RR-c; b) if RR-c cost is unavailable for whatever reason RR will use > its own cost. Note that original idea is that RR-c informs RR about > all costs. If network policies call for non-IGP preference, then > RR-c can use ever-increasing numbers calculated in a way operator > prefers. First N (number of preferred exits) can be explicitly > configured on RR-c, the rest RR-c will calculate itself by ordering > IGP costs of remaining exits. To give an example: a PE prefers NH5 > and NH9, which operator configures on the PE manually. Let's say at > some moment _all_ prefixes are reachable via set of next-hops > NH1,NH2,...,NH50. PE sends following info to RR: first it tells that > NH5:cost1, NH9:cost2 (because it configured by operator), then PE > takes remaining next-hops and arranges them in order of increasing > IGP cost behind first two next-hops, the cost reported for NH-i to > RR is the position of that NH-i in the just created list. When IGP > cost to non-preferred next-hops changes (due to topology change), PE > just re-evaluates NH order and sends updated cost to RR. When > preferred ASBR's are not available as feasible path to certain > prefix, RR just uses whatever is next NH in the list received from > RR-c but only for prefixes where preferred ASBR is not feasible > exit. When preferred ASBR's fail (i.e. no path can be reached via > them), RR uses for whatever is next NH in the list received from > RR-c for all prefixes. So in general, when certain prefix cannot be > reached via preferred ASBR's (regardless of the reason) then RR uses > next NH in the list received from RR-c. If for some reason > connectivity from RR-c to ASBR fails, RR-c will inform RR that > particular NH is no longer feasible (as described in NH SAFI draft) > and RR will stop considering that ASBR when calculating routes for > given RR-c (even if from RR perspective or from any other router > perspective that very same ASBR is still reachable). Same question > as above - do you feel such behaviour should be explicitly spelled > out even though it's natural? > > Kind regards, > iLya > From vjoseph@juniper.net Sun Jun 12 12:12:21 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B9B11E8128 for ; Sun, 12 Jun 2011 12:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmlJX+oFWBdx for ; Sun, 12 Jun 2011 12:12:21 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5767E11E811B for ; Sun, 12 Jun 2011 12:12:13 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUPimb2TMbMBu8Kukcg0amP3agd7hDE@postini.com; Sun, 12 Jun 2011 12:12:20 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 12:09:53 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 20:09:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 20:09:48 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE11@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpM7RtJ/X115PjTQW6bpcKb/1oewAACmxg References: <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0D@emailemea4.jnpr.net> <4D F50DF7.7 090909@cisco.com> From: Vinod Joseph To: X-OriginalArrivalTime: 12 Jun 2011 19:09:51.0761 (UTC) FILETIME=[4E6B8810:01CC2934] Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:12:21 -0000 Robert, I think I understand that very well, but thanks for the tip :-). The = proposal takes care of that. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 20:05 To: Vinod Joseph Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection Vinod, > Vinod# The proposed draft intends to permit the use of RT signalling > via RTC without the need for those specific RTs to be configured in > every BGP speaker. If RTC capability is exchanged and no RT is signaled default behaviour=20 is not to send any routes towards such PE. Keep that in mind in your next version. > "ALL" or "N" number of paths using ADD-PATH. Are you also going to extend add-path spec to carry how many prefixes is = required for given policy based exit PE ? If not how would the RR know=20 how many paths to send to a given PE ? R. From vjoseph@juniper.net Sun Jun 12 12:18:29 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A963811E812E for ; Sun, 12 Jun 2011 12:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC741y+8fOlz for ; Sun, 12 Jun 2011 12:18:28 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 80EEB11E811F for ; Sun, 12 Jun 2011 12:18:18 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUQ+bP+prTgI6wMzrH3oIGG7xqFb1yE@postini.com; Sun, 12 Jun 2011 12:18:28 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 12:13:10 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 20:13:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 20:13:03 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE15@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpNHRvaDyrd4RtTnii6nDo29h5mgAACIAA References: <243870.49492.qm@web37903.mail.mud.yahoo.com> <5DD781A4BE13384A900438DF0608972C06A1FE0F@emailemea4.jnpr.net> <4DF50F39.3070509@cisco.com> From: Vinod Joseph To: X-OriginalArrivalTime: 12 Jun 2011 19:13:07.0489 (UTC) FILETIME=[C3154110:01CC2934] Cc: IETF IDR , bruno.decraene@orange-ftgroup.com, gaurav.thareja@gmail.com, Chintan.Shah@colt.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:18:29 -0000 Personally I do not find them embedded, but if you feel so, then we = should wait! Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 20:11 To: Vinod Joseph Cc: Reshmi Prem; Ilya Varlashkin; gaurav.thareja@gmail.com; = bruno.decraene@orange-ftgroup.com; Chintan.Shah@colt.net; IETF IDR Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection Vinod, I would like to clarify however the questions are so embedded that they=20 are hard to understand. Perhaps author of them could restate them more=20 clearly. Thx, R. > Still waiting for inputs on this, Robert can you clarify this please? > > Regards > > *Vinod Joseph*** > > Professional Services - Service Provider Europe > > Juniper Networks > > M: +44 (0) 7500 835 876 > > E:vjoseph@juniper.net > > cid:image003.gif@01CA5909.95D8EDC0 > > > *From:*Reshmi Prem [mailto:reshmi_prem@yahoo.com] > *Sent:* 10 June 2011 20:39 > *To:* Ilya Varlashkin > *Cc:* raszuk@cisco.com Raszuk; Vinod Joseph; gaurav.thareja@gmail.com; > bruno.decraene@orange-ftgroup.com; Chintan.Shah@colt.net; IETF IDR > *Subject:* Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection > > Illya: > > ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. = As > long as you don't do anything what other specification forbids, do you > need to describe every possible combination of features that could be > used together? Today you can use ADD-PATH to send multiple PATHs, > tomorrow there will be another solution to do it. NH SAFI neither > forbids nor requires you to use any other BGP feature beyond what's > specified in the drafts, so by all means if you want multiple best = PATHs > from RR-client perspective you can combine NH SAFI with ADD-PATH. If = you > don't need multiple paths, you just don't use multiple paths. Do you > feel this combination should be explicitly spelled in the NH SAFI = specs? > > >>>>>>>>>>>>>>> You are talking about using ADD-PATH to choose a = select > no. of paths based only on admin costs that are statically specified = on > the PE. This needs some work or integration or extension or whatever = you > call it, to ADD-PATH. You need to mention this in your draft. > > ok, implicit assumption is that RR will use a) cost provided by RR-c; = b) > if RR-c cost is unavailable for whatever reason RR will use its own > cost. Note that original idea is that RR-c informs RR about all costs. > If network policies call for non-IGP preference, then RR-c can use > ever-increasing numbers calculated in a way operator prefers. First N > (number of preferred exits) can be explicitly configured on RR-c, the > rest RR-c will calculate itself by ordering IGP costs of remaining > exits. To give an example: a PE prefers NH5 and NH9, which operator > configures on the PE manually. Let's say at some moment _all_ prefixes > are reachable via set of next-hops NH1,NH2,...,NH50. PE sends = following > info to RR: first it tells that NH5:cost1, NH9:cost2 (because it > configured by operator), then PE takes remaining next-hops and = arranges > them in order of increasing IGP cost behind first two next-hops, the > cost reported for NH-i to RR is the position of that NH-i in the just > created list. When IGP cost to non-preferred next-hops changes (due to > topology change), PE just re-evaluates NH order and sends updated cost > to RR. When preferred ASBR's are not available as feasible path to > certain prefix, RR just uses whatever is next NH in the list received > from RR-c but only for prefixes where preferred ASBR is not feasible > exit. When preferred ASBR's fail (i.e. no path can be reached via = them), > RR uses for whatever is next NH in the list received from RR-c for all > prefixes. So in general, when certain prefix cannot be reached via > preferred ASBR's (regardless of the reason) then RR uses next NH in = the > list received from RR-c. If for some reason connectivity from RR-c to > ASBR fails, RR-c will inform RR that particular NH is no longer = feasible > (as described in NH SAFI draft) and RR will stop considering that ASBR > when calculating routes for given RR-c (even if from RR perspective or > from any other router perspective that very same ASBR is still > reachable). Same question as above - do you feel such behaviour should > be explicitly spelled out even though it's natural? > > >>>>>>>>>>>>>>>>I am lost sorry. Simple example: network has 10 = ASBRs. > PE1 says ASBR1=3DMETRIC15 and ASBR2=3DMETRIC20 and sends this info to = the > RR. Now RR reflects both these ASBR paths to PE1 with the same = metrics? > > >>>>>>>>>>>>>>>>>>>>PE1 automatically calculates IGP Cost to ASBR = 3--10? > > >>>>>>>>>>>>>>>>>>>>>>> Assume ASBR 3-10 have metrics as follows > ASBR3=3D3, ASBR4=3D4 .....ASBR10=3D10, This can happen right? > > >>>>>>>>>>>>>>>>>>>>>>>>>> RR advertises ASBR 3 TO ASBR 10 paths to = PE1? > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does RR ensure that non candidate > (preferred paths) are not announced to the PE upfront? > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How do you ensure that non candidate > paths always have a higher metric than candidate paths? > > - Prem > > --- On *Fri, 6/10/11, Ilya Varlashkin //* wrote: > > > From: Ilya Varlashkin > Subject: Re: [Idr] = draft-vinod-lavallee-bgp-optimal-route-reflection > To: "Reshmi Prem" > Cc: "raszuk@cisco.com Raszuk" , "Vinod Joseph" > , gaurav.thareja@gmail.com, > bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, "IETF = IDR" > > Date: Friday, June 10, 2011, 2:04 PM > > On Jun 10, 2011, at 19:21 , Reshmi Prem wrote: > > > Ilya, > > > > I did not see your draft specifying that you would be using > ADD-PATH, Can you confirm this? > > > > ehrm...use of ADD-PATH is not feature of NH SAFI, but = of...ADD-PATH. > As long as you don't do anything what other specification forbids, > do you need to describe every possible combination of features = that > could be used together? Today you can use ADD-PATH to send = multiple > PATHs, tomorrow there will be another solution to do it. NH SAFI > neither forbids nor requires you to use any other BGP feature = beyond > what's specified in the drafts, so by all means if you want = multiple > best PATHs from RR-client perspective you can combine NH SAFI with > ADD-PATH. If you don't need multiple paths, you just don't use > multiple paths. Do you feel this combination should be explicitly > spelled in the NH SAFI specs? > > > Vinod's draft specifies a means of using an RR specific RT to > permit a RR calculated best path in addition to RTC specified = paths. > How does your draft handle this? What happens if the list of ASBRS > that i indicate a metric for disappear?? > > ok, implicit assumption is that RR will use a) cost provided by > RR-c; b) if RR-c cost is unavailable for whatever reason RR will = use > its own cost. Note that original idea is that RR-c informs RR = about > all costs. If network policies call for non-IGP preference, then > RR-c can use ever-increasing numbers calculated in a way operator > prefers. First N (number of preferred exits) can be explicitly > configured on RR-c, the rest RR-c will calculate itself by = ordering > IGP costs of remaining exits. To give an example: a PE prefers NH5 > and NH9, which operator configures on the PE manually. Let's say = at > some moment _all_ prefixes are reachable via set of next-hops > NH1,NH2,...,NH50. PE sends following info to RR: first it tells = that > NH5:cost1, NH9:cost2 (because it configured by operator), then PE > takes remaining next-hops and arranges them in order of increasing > IGP cost behind first two next-hops, the cost reported for NH-i to > RR is the position of that NH-i in the just created list. When IGP > cost to non-preferred next-hops changes (due to topology change), = PE > just re-evaluates NH order and sends updated cost to RR. When > preferred ASBR's are not available as feasible path to certain > prefix, RR just uses whatever is next NH in the list received from > RR-c but only for prefixes where preferred ASBR is not feasible > exit. When preferred ASBR's fail (i.e. no path can be reached via > them), RR uses for whatever is next NH in the list received from > RR-c for all prefixes. So in general, when certain prefix cannot = be > reached via preferred ASBR's (regardless of the reason) then RR = uses > next NH in the list received from RR-c. If for some reason > connectivity from RR-c to ASBR fails, RR-c will inform RR that > particular NH is no longer feasible (as described in NH SAFI = draft) > and RR will stop considering that ASBR when calculating routes for > given RR-c (even if from RR perspective or from any other router > perspective that very same ASBR is still reachable). Same question > as above - do you feel such behaviour should be explicitly spelled > out even though it's natural? > > Kind regards, > iLya > From raszuk@cisco.com Sun Jun 12 12:35:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389C321F8496 for ; Sun, 12 Jun 2011 12:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.397 X-Spam-Level: X-Spam-Status: No, score=-10.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmHDYXYmGz4M for ; Sun, 12 Jun 2011 12:35:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id B836521F8495 for ; Sun, 12 Jun 2011 12:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=389; q=dns/txt; s=iport; t=1307907300; x=1309116900; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wBnnng5RKS6TkXhATmnmU8Af9atNpwVk7NllKgIdYXc=; b=cA8wRnMKU5q8ocudELfsIzB/soyOLQ9OWUPN+RlpDdRM3VlZCntihq6n fQBYQORbAk0JfaBmrPj+EH4l8MOYrNyFyObwcwKHjTu66XRFjwoyCv3R3 CNd8Qtlc9/69urn4DysEozeMyxfua8ggA6Jjt1inidPv0AqQbztPuycMW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANMT9U2rRDoI/2dsb2JhbABSpk93iHKiC4MODwGZYoYkBJE0hE+LEA X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="464088885" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2011 19:35:00 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5CJYv22029234; Sun, 12 Jun 2011 19:34:58 GMT Message-ID: <4DF514E2.6000407@cisco.com> Date: Sun, 12 Jun 2011 21:34:58 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:35:01 -0000 Vinod, > The changes to the original RTC specification will be clearly > addressed in version 0.1. I do not want to get into a debate with you > on whether we should be having 2 drafts etc. Consider it please as a formal input that I do not agree to modify base behavior and design principles of RFC4684 by any other document then a separate spec dedicated to it. Thx, R. From vjoseph@juniper.net Sun Jun 12 12:44:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28911E813A for ; Sun, 12 Jun 2011 12:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BK3f0d4NQIK for ; Sun, 12 Jun 2011 12:44:44 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id A4F5111E80E9 for ; Sun, 12 Jun 2011 12:44:39 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUXI2XJTEp6a3HdwGd5MCQ6VkMRdgjv@postini.com; Sun, 12 Jun 2011 12:44:44 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 12:37:16 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 20:37:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 20:37:12 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE1A@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpN9RXIPoHWnn7RWaBDf2pWMy2HwAABRUQ References: <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> <4DF514E2.6000407@c isco.com > From: Vinod Joseph To: X-OriginalArrivalTime: 12 Jun 2011 19:37:14.0748 (UTC) FILETIME=[21B773C0:01CC2938] Cc: idr@ietf.org, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:44:45 -0000 Any input on the list from everyone is considered as formal input = Robert, so there is no exception to that. Be rest assured. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 20:35 To: Vinod Joseph Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Vinod, > The changes to the original RTC specification will be clearly > addressed in version 0.1. I do not want to get into a debate with you > on whether we should be having 2 drafts etc. Consider it please as a formal input that I do not agree to modify base=20 behavior and design principles of RFC4684 by any other document then a=20 separate spec dedicated to it. Thx, R. From vjoseph@juniper.net Sun Jun 12 12:50:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C811E80C4 for ; Sun, 12 Jun 2011 12:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXGQ3TSKPWZt for ; Sun, 12 Jun 2011 12:50:22 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id DC96B11E8147 for ; Sun, 12 Jun 2011 12:50:10 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTfUYcMA20/18YE61cczOFiJeiVJrOxgj@postini.com; Sun, 12 Jun 2011 12:50:18 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Sun, 12 Jun 2011 12:46:24 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 20:46:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 20:46:19 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FE1B@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpN9RXIPoHWnn7RWaBDf2pWMy2HwAAY5UQ References: <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> <4DF514E2.6000407@c isco.com > From: Vinod Joseph To: X-OriginalArrivalTime: 12 Jun 2011 19:46:22.0542 (UTC) FILETIME=[683A2EE0:01CC2939] Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:50:22 -0000 That puts an interesting challenge to AF independent code which in most=20 BGP implementations is BGP best path calculation.=20 Vinod: Interesting. Is'nt your ORR draft modifying the BGP best path = calculation? And for IPv4 and possibly IPv6 on the RR?? Keen to = understand this, since we are now speaking from a vendors implementation = perspective. For one AF this should work very differently then for the other. Also it = should work differently on RR then on ASBR. Vinod: On the RR yes, Best path only for if PE signals an RT that is = allocated to the RR - Where we want to only have the best path announced = and NOT in other cases. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 20:35 To: Vinod Joseph Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments on = draft-vinod-lavallee-bgp-optimal-route-reflection Vinod, > The changes to the original RTC specification will be clearly > addressed in version 0.1. I do not want to get into a debate with you > on whether we should be having 2 drafts etc. Consider it please as a formal input that I do not agree to modify base=20 behavior and design principles of RFC4684 by any other document then a=20 separate spec dedicated to it. Thx, R. From raszuk@cisco.com Sun Jun 12 12:59:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F6822800E for ; Sun, 12 Jun 2011 12:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.402 X-Spam-Level: X-Spam-Status: No, score=-10.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzjQ4g9I-F4a for ; Sun, 12 Jun 2011 12:59:49 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id F240811E80BA for ; Sun, 12 Jun 2011 12:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=552; q=dns/txt; s=iport; t=1307908788; x=1309118388; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BGvqK0l0DrBHz0SLpmO9KAknBAeaPOVWHjaMyQQmrx4=; b=Q4/f1FBN84ligF6fzwqhBIDrz1tVqmIPdX31xCCdcQmA7flp2sYGG6Cb CNWlDwok74jyTKBL8nNs+RjThdduInvrdRs36rNE5QDFdYEV7iV2rb/It PSbKkyyhH0ef4izuafsN9ie9tROyY2oSZCx37hiGOuAXD3QEQa/7jKb26 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKgZ9U2rRDoJ/2dsb2JhbABSpk93iHKiCoMODwGZX4YkBJE0hE+LEA X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="335409827" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2011 19:59:48 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5CJxkWG007128; Sun, 12 Jun 2011 19:59:46 GMT Message-ID: <4DF51AB3.9060404@cisco.com> Date: Sun, 12 Jun 2011 21:59:47 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> <4DF514E2.6000407@cisco.com > <5DD781A4BE13384A900438DF0608972C06A1FE1A@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE1A@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 19:59:49 -0000 Vinod, Let me clarify as you did not get it. As co-author of RFC4684 I would like to clearly state that I do not agree to modify base behavior and design principles of RFC4684 by any other document then a separate spec dedicated to it. Best regards, R. > Any input on the list from everyone is considered as formal input > Robert, so there is no exception to that. > > Be rest assured. > > Regards Vinod Joseph Professional Services - Service > Provider Europe Juniper Networks > M: +44 (0) 7500 835 876 E: vjoseph@juniper.net From raszuk@cisco.com Sun Jun 12 13:07:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070AF11E807B for ; Sun, 12 Jun 2011 13:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.107 X-Spam-Level: X-Spam-Status: No, score=-10.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8vsJ7z+bCHZ for ; Sun, 12 Jun 2011 13:07:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 614B611E80C4 for ; Sun, 12 Jun 2011 13:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=628; q=dns/txt; s=iport; t=1307909274; x=1309118874; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EsH/882JsOcizJDU1eeX8c2Sbx0B/xPqT1HAzW2xveI=; b=lbuMkxdkvyWgT88Cl0xWesn55x3WTs/NYECAnFxr/vcU/s3/ArBPb/zZ Soipk7b+Sw/Yh/usx0MEIsxc+bBkwF9pGDxpDJPRjo/+7Emmv9mv5o2L0 EGiG4kOrQ4gdaFiW+XatKfW/3XMDQkh/Btg5cqiwJu/WLAVrFucGntbTS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMYb9U2rRDoI/2dsb2JhbABSpk93iHKhdoMODwGZXoYkBJE0hE+LEA X-IronPort-AV: E=Sophos;i="4.65,355,1304294400"; d="scan'208";a="712222903" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2011 20:07:54 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5CK7poH007891; Sun, 12 Jun 2011 20:07:52 GMT Message-ID: <4DF51C98.4030809@cisco.com> Date: Sun, 12 Jun 2011 22:07:52 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Vinod Joseph References: <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> <4DF514E2.6000407@cisco.com > <5DD781A4BE13384A900438DF0608972C06A1FE1B@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE1B@emailemea4.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 20:07:55 -0000 Vinod, > That puts an interesting challenge to AF independent code which in > most BGP implementations is BGP best path calculation. > > Vinod: Interesting. Is'nt your ORR draft modifying the BGP best path > calculation? And for IPv4 and possibly IPv6 on the RR?? Keen to > understand this, since we are now speaking from a vendors > implementation perspective. It does not need to if you implement it right. Sorry for being dense but I hope you will understand that. However IDR WG ORR spec does not impact or changes an existing behavior of any other BGP extension. That is a significant difference. r. From jakob.heitz@ericsson.com Sun Jun 12 21:50:56 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7C01F0C41 for ; Sun, 12 Jun 2011 21:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.51 X-Spam-Level: X-Spam-Status: No, score=-4.51 tagged_above=-999 required=5 tests=[AWL=2.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH0RW4ZDRBmL for ; Sun, 12 Jun 2011 21:50:55 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id CBC091F0C40 for ; Sun, 12 Jun 2011 21:50:55 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5D4oooH009136; Sun, 12 Jun 2011 23:50:51 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 13 Jun 2011 00:50:45 -0400 From: Jakob Heitz To: Vinod Joseph , "idr@ietf.org" Date: Mon, 13 Jun 2011 00:50:43 -0400 Thread-Topic: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpMoWGsKVhGhwNTU2dLiRdff5VoAAAFtmgABRkBdA= Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E4083046B@EUSAACMS0701.eamcs.ericsson.se> References: <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> In-Reply-To: <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.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 Cc: "laurent.lavallee@sns.bskyb.com" , "raszuk@cisco.com" , Amit Khopkar , "Chintan.Shah@colt.net" , "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 04:50:56 -0000 Before you do that, I'd like to hear from some of the less vocal operators. What are your pain points? What is difficult or impossible to do? I have seen 2 requirements so far: 1. For a PE to prefer routes from a given set of ASBR's. 2. For premium customers to prefer routes from a given set of ASBR's. For calrification: How is a premium customer identified? Is it one that owns a particular IP address? Is it one that connects to a particular interface on the PE? Something else? -- Jakob Heitz. =20 > -----Original Message----- > From: Vinod Joseph [mailto:vjoseph@juniper.net]=20 > Sent: Sunday, June 12, 2011 12:04 PM >=20 > Version 0.1 will be submitted based on the feedback and views=20 > of the many operators on this list. >=20 From raszuk@cisco.com Sun Jun 12 23:42:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1188A11E8096 for ; Sun, 12 Jun 2011 23:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.404 X-Spam-Level: X-Spam-Status: No, score=-10.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRYVjZt9gUBA for ; Sun, 12 Jun 2011 23:42:21 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7419611E808D for ; Sun, 12 Jun 2011 23:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1595; q=dns/txt; s=iport; t=1307947341; x=1309156941; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7FBfQlqI5r2QGm7mqzoONMT/RwUyBYzQZBTLpfcX6ME=; b=A5v2NjAnUHXbaQ/vEzEY/L53zL5lp5ux0xkBopbGW3VQawWdEhV6BLHm nksSZoixyO67jmXQPwgnBWvZfCY8POxMBc0xdDMBMi8/QXLISJf3yqp+/ eNs3GGNlgyKEYM/LljUBjQAHzlAh6deIeXIpOG/IUL5cBQrte2aDSdAbb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBACix9U2rRDoI/2dsb2JhbABSl1KOeHeIcqESgw4PAZoDhiQEkTSET4sQ X-IronPort-AV: E=Sophos;i="4.65,356,1304294400"; d="scan'208";a="464228746" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2011 06:42:10 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5D6g7J6005941; Mon, 13 Jun 2011 06:42:08 GMT Message-ID: <4DF5B140.9060906@cisco.com> Date: Mon, 13 Jun 2011 08:42:08 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jakob Heitz References: <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0C@emailemea4.jnpr.net> <4DF50BFA.1 050905@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0E@emailemea4.jnpr.net> <7309FCBCAE981B43ABBE69B31C8D21390E4083046B@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E4083046B@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" , "laurent.lavallee@sns.bskyb.com" , Vinod Joseph , Amit Khopkar , "Chintan.Shah@colt.net" , "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 06:42:22 -0000 Hi Jakob, In fact I have a better question ... how is the "premium" ASBR identified ? What determines that premium today will be premium tomorrow ? How do you map Internet topology changes to the static selection of "premium" exit point from any network. And of course I will not take "operator's policy" as an answer ;). Can anyone guarantee that even if I have painted gold ASBR with 10 GB pipe to best tier one of the world all Internet reachability there will be always better then what would 10 silver painted ASBRs give me from mix of paths received from various tier 1's or tier 2's ? Different products exist today from multiple vendors to address such task on a destination prefix granularity, but non of them is based on a static mapping to any ASBR. Rgs, R. > Before you do that, I'd like to hear from some of the > less vocal operators. What are your pain points? > What is difficult or impossible to do? > > I have seen 2 requirements so far: > 1. For a PE to prefer routes from a given set of ASBR's. > 2. For premium customers to prefer routes from a given set of ASBR's. > > For calrification: How is a premium customer identified? > Is it one that owns a particular IP address? > Is it one that connects to a particular interface on the PE? > Something else? > > -- > Jakob Heitz. > > >> -----Original Message----- >> From: Vinod Joseph [mailto:vjoseph@juniper.net] >> Sent: Sunday, June 12, 2011 12:04 PM >> >> Version 0.1 will be submitted based on the feedback and views >> of the many operators on this list. >> > From raszuk@cisco.com Mon Jun 13 07:38:15 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E696228015 for ; Mon, 13 Jun 2011 07:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.409 X-Spam-Level: X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btyp4DNAa0Bv for ; Mon, 13 Jun 2011 07:38:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0E939228013 for ; Mon, 13 Jun 2011 07:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=8605; q=dns/txt; s=iport; t=1307975894; x=1309185494; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Qaht/q1MZjpatL0rYC9jL2Z/Yc8VIGskH775mEpGDE0=; b=anLv6oYvq6EJdqwPH0AO7x9/Gn4zL2nBdA1PXlNGDkIvmZMyR8VDIeQe Rd52BOPWU+Uuzt2y6s0yYjrorXf0CM0qhARcx5smQnBvGgmzQjZ1RcDb4 P0uKsajVbS0SqkmaoYCf63V+nYm4jtgc5FM3XuG8zq4Nc87ktsfsypo5Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncBAL4f9k2rRDoI/2dsb2JhbABSl1QPjlZ3iHKhaIMODwGaI4YkBJE0hE+EQIZQ X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="375564998" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2011 14:38:13 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5DEcAdJ020894; Mon, 13 Jun 2011 14:38:11 GMT Message-ID: <4DF620D2.1020203@cisco.com> Date: Mon, 13 Jun 2011 16:38:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Reshmi Prem References: <243870.49492.qm@web37903.mail.mud.yahoo.com> In-Reply-To: <243870.49492.qm@web37903.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR , bruno.decraene@orange-ftgroup.com, Vinod Joseph , gaurav.thareja@gmail.com, Chintan.Shah@colt.net Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 14:38:15 -0000 Dear Reshmi, Thanks for your feedback. It seems you have recently joined this WG discussion and because you are using your private email address it would be great if you could introduce yourself and your company/role association to allow us to better put your contributions into perspective. Once you respond I will be happy to address your points in the below email. Emily Postnews would recommend a signature, eg: Reshmi Prem Shrub Tree Networks "The true voice of the operator" > Illya: > ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As > long as you don't do anything what other specification forbids, do you > need to describe every possible combination of features that could be > used together? Today you can use ADD-PATH to send multiple PATHs, > tomorrow there will be another solution to do it. NH SAFI neither > forbids nor requires you to use any other BGP feature beyond what's > specified in the drafts, so by all means if you want multiple best PATHs > from RR-client perspective you can combine NH SAFI with ADD-PATH. If you > don't need multiple paths, you just don't use multiple paths. Do you > feel this combination should be explicitly spelled in the NH SAFI specs? > >>>>>>>>>>>>>>> You are talking about using ADD-PATH to choose a select > no. of paths based only on admin costs that are statically specified on > the PE. This needs some work or integration or extension or whatever you > call it, to ADD-PATH. You need to mention this in your draft. > ok, implicit assumption is that RR will use a) cost provided by RR-c; b) > if RR-c cost is unavailable for whatever reason RR will use its own > cost. Note that original idea is that RR-c informs RR about all costs. > If network policies call for non-IGP preference, then RR-c can use > ever-increasing numbers calculated in a way operator prefers. First N > (number of preferred exits) can be explicitly configured on RR-c, the > rest RR-c will calculate itself by ordering IGP costs of remaining > exits. To give an example: a PE prefers NH5 and NH9, which operator > configures on the PE manually. Let's say at some moment _all_ prefixes > are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following > info to RR: first it tells that NH5:cost1, NH9:cost2 (because it > configured by operator), then PE takes remaining next-hops and arranges > them in order of increasing IGP cost behind first two next-hops, the > cost reported for NH-i to RR is the position of that NH-i in the just > created list. When IGP cost to non-preferred next-hops changes (due to > topology change), PE just re-evaluates NH order and sends updated cost > to RR. When preferred ASBR's are not available as feasible path to > certain prefix, RR just uses whatever is next NH in the list received > from RR-c but only for prefixes where preferred ASBR is not feasible > exit. When preferred ASBR's fail (i.e. no path can be reached via them), > RR uses for whatever is next NH in the list received from RR-c for all > prefixes. So in general, when certain prefix cannot be reached via > preferred ASBR's (regardless of the reason) then RR uses next NH in the > list received from RR-c. If for some reason connectivity from RR-c to > ASBR fails, RR-c will inform RR that particular NH is no longer feasible > (as described in NH SAFI draft) and RR will stop considering that ASBR > when calculating routes for given RR-c (even if from RR perspective or > from any other router perspective that very same ASBR is still > reachable). Same question as above - do you feel such behaviour should > be explicitly spelled out even though it's natural? > >>>>>>>>>>>>>>>>I am lost sorry. Simple example: network has 10 ASBRs. > PE1 says ASBR1=METRIC15 and ASBR2=METRIC20 and sends this info to the > RR. Now RR reflects both these ASBR paths to PE1 with the same metrics? > >>>>>>>>>>>>>>>>>>>>PE1 automatically calculates IGP Cost to ASBR 3--10? > >>>>>>>>>>>>>>>>>>>>>>> Assume ASBR 3-10 have metrics as follows > ASBR3=3, ASBR4=4 .....ASBR10=10, This can happen right? > >>>>>>>>>>>>>>>>>>>>>>>>>> RR advertises ASBR 3 TO ASBR 10 paths to PE1? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does RR ensure that non candidate > (preferred paths) are not announced to the PE upfront? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How do you ensure that non candidate > paths always have a higher metric than candidate paths? > - Prem > > --- On *Fri, 6/10/11, Ilya Varlashkin //* wrote: > > > From: Ilya Varlashkin > Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection > To: "Reshmi Prem" > Cc: "raszuk@cisco.com Raszuk" , "Vinod Joseph" > , gaurav.thareja@gmail.com, > bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, "IETF IDR" > > Date: Friday, June 10, 2011, 2:04 PM > > On Jun 10, 2011, at 19:21 , Reshmi Prem wrote: > > > Ilya, > > > > I did not see your draft specifying that you would be using > ADD-PATH, Can you confirm this? > > > > ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. > As long as you don't do anything what other specification forbids, > do you need to describe every possible combination of features that > could be used together? Today you can use ADD-PATH to send multiple > PATHs, tomorrow there will be another solution to do it. NH SAFI > neither forbids nor requires you to use any other BGP feature beyond > what's specified in the drafts, so by all means if you want multiple > best PATHs from RR-client perspective you can combine NH SAFI with > ADD-PATH. If you don't need multiple paths, you just don't use > multiple paths. Do you feel this combination should be explicitly > spelled in the NH SAFI specs? > > > Vinod's draft specifies a means of using an RR specific RT to > permit a RR calculated best path in addition to RTC specified paths. > How does your draft handle this? What happens if the list of ASBRS > that i indicate a metric for disappear?? > > ok, implicit assumption is that RR will use a) cost provided by > RR-c; b) if RR-c cost is unavailable for whatever reason RR will use > its own cost. Note that original idea is that RR-c informs RR about > all costs. If network policies call for non-IGP preference, then > RR-c can use ever-increasing numbers calculated in a way operator > prefers. First N (number of preferred exits) can be explicitly > configured on RR-c, the rest RR-c will calculate itself by ordering > IGP costs of remaining exits. To give an example: a PE prefers NH5 > and NH9, which operator configures on the PE manually. Let's say at > some moment _all_ prefixes are reachable via set of next-hops > NH1,NH2,...,NH50. PE sends following info to RR: first it tells that > NH5:cost1, NH9:cost2 (because it configured by operator), then PE > takes remaining next-hops and arranges them in order of increasing > IGP cost behind first two next-hops, the cost reported for NH-i to > RR is the position of that NH-i in the just created list. When IGP > cost to non-preferred next-hops changes (due to topology change), PE > just re-evaluates NH order and sends updated cost to RR. When > preferred ASBR's are not available as feasible path to certain > prefix, RR just uses whatever is next NH in the list received from > RR-c but only for prefixes where preferred ASBR is not feasible > exit. When preferred ASBR's fail (i.e. no path can be reached via > them), RR uses for whatever is next NH in the list received from > RR-c for all prefixes. So in general, when certain prefix cannot be > reached via preferred ASBR's (regardless of the reason) then RR uses > next NH in the list received from RR-c. If for some reason > connectivity from RR-c to ASBR fails, RR-c will inform RR that > particular NH is no longer feasible (as described in NH SAFI draft) > and RR will stop considering that ASBR when calculating routes for > given RR-c (even if from RR perspective or from any other router > perspective that very same ASBR is still reachable). Same question > as above - do you feel such behaviour should be explicitly spelled > out even though it's natural? > > Kind regards, > iLya > From vjoseph@juniper.net Mon Jun 13 13:23:43 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0B11E80FF for ; Mon, 13 Jun 2011 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uj786aM3IEk for ; Mon, 13 Jun 2011 13:23:42 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id B002711E807B for ; Mon, 13 Jun 2011 13:23:34 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTfZxw1b2d5riwnOGCHYLm/rUQNFLuzK4@postini.com; Mon, 13 Jun 2011 13:23:41 PDT Received: from emailfeemea2.jnpr.net (172.26.192.142) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Mon, 13 Jun 2011 13:20:34 -0700 Received: from emailemea4.jnpr.net ([172.26.192.133]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 21:20:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2011 21:20:28 +0100 Message-ID: <5DD781A4BE13384A900438DF0608972C06A1FF52@emailemea4.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwpM7RtJ/X115PjTQW6bpcKb/1oewAzzfZQ References: <2491F56A4456476FA2EDD65297696BF9@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996D90@emailemea4.jnpr.net> <5A91223E080242C3A52A6BD444BA3B90@hnivarlas1> <5DD781A4BE13384A900438DF0608972C06996DCB@emailemea4.jnpr.net> <9B986DAFCDA24BB8B890B7A4B90F7627@hnivarlas1> <4DEE50D0.6070608@cisco.com> <5DD781A4BE13384A900438DF0608972C06996F8F@emailemea4.jnpr.net> <28034_1307535916_4DEF6A2C_28034_21684_1_4FC3556A36EE3646A09DAA60429F5335067BBA0F@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C069970C8@emailemea4.jnpr.net> <28477_1307539982_4DEF7A0E_28477_26823_1_4FC3556A36E E3646A09DAA6 0429F5335067BBAA9@PUEXCBL0.nanterre.francetelecom.fr> <5DD781A4BE13384A900438DF0608972C06A1FE0A@emailemea4.jnpr.net> <4DF50900.6080302@cisco.com> <5DD781A4BE13384A900438DF0608972C06A1FE0D@emailemea4.jnpr.net> <4D F50DF7.7 090909@cisco.com> From: Vinod Joseph To: X-OriginalArrivalTime: 13 Jun 2011 20:20:32.0919 (UTC) FILETIME=[58C2A270:01CC2A07] Cc: idr@ietf.org, laurent.lavallee@sns.bskyb.com, Amit Khopkar , Chintan.Shah@colt.net, "Thareja, Gaurav" Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 20:23:43 -0000 Robert, I just had a relook of your email and I think we are talking about two = different things. I meant to say that the BGP speaker need not have its prefixes tagged = with a specific RT for those RTs to be signalled via RT Constrain. This = does not mean, that the RTC will not carry any RT, neither does this = mean any modification to RTC behaviour - in this context.=20 Check Section 5.7 of the Draft. The draft makes it clear(for = completeness) that tagging the prefixes with an RT, vs. indicating = preferences via RT constrain are two separate things. So ASBR is = configured with its prefixes tagged using specific RTs, and PEs would = signal interest via RTC. If certain circumstances demand that, the PE = needs to tag specific RTs to prefixes - to influence the traffic flows, = then it can do it as well. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper = Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M: +44 (0) 7500 835 876 E:=A0vjoseph@juniper.net =A0 -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com]=20 Sent: 12 June 2011 20:05 To: Vinod Joseph Cc: Jakob Heitz; stephane.litkowski@orange-ftgroup.com; idr@ietf.org; = Thareja, Gaurav; Amit Khopkar; Chintan.Shah@colt.net; = laurent.lavallee@sns.bskyb.com Subject: Re: [Idr] Comments = ondraft-vinod-lavallee-bgp-optimal-route-reflection Vinod, > Vinod# The proposed draft intends to permit the use of RT signalling > via RTC without the need for those specific RTs to be configured in > every BGP speaker. If RTC capability is exchanged and no RT is signaled default behaviour=20 is not to send any routes towards such PE. Keep that in mind in your next version. > "ALL" or "N" number of paths using ADD-PATH. Are you also going to extend add-path spec to carry how many prefixes is = required for given policy based exit PE ? If not how would the RR know=20 how many paths to send to a given PE ? R. From ietfc@btconnect.com Wed Jun 15 01:52:46 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E476611E809D for ; Wed, 15 Jun 2011 01:52:46 -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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZcQDaRP9G-N for ; Wed, 15 Jun 2011 01:52:46 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5EE11E809B for ; Wed, 15 Jun 2011 01:52:44 -0700 (PDT) Received: from host81-156-207-154.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.154]) by c2beaomr06.btconnect.com with SMTP id DKX79761; Wed, 15 Jun 2011 09:52:38 +0100 (BST) Message-ID: <000b01cc2b30$e485cba0$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "Reshmi Prem" References: <243870.49492.qm@web37903.mail.mud.yahoo.com> <4DF620D2.1020203@cisco.com> Date: Wed, 15 Jun 2011 09:49:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4DF872D4.011E, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.15.74216:17:7.586, ip=81.156.207.154, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, ECARD_KNOWN_DOMAINS, __FRAUD_CONTACT, BODY_SIZE_10000_PLUS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4DF872D7.0158,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: IETF IDR Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 08:52:47 -0000 ----- Original Message ----- From: "Robert Raszuk" To: "Reshmi Prem" Cc: "IETF IDR" ; ; "Vinod Joseph" ; ; Sent: Monday, June 13, 2011 4:38 PM > Dear Reshmi, > > Thanks for your feedback. It seems you have recently joined this WG > discussion and because you are using your private email address it would > be great if you could introduce yourself and your company/role > association to allow us to better put your contributions into > perspective. Once you respond I will be happy to address your points > in the below email. Robert An interesting request but not one that I think Reshmi need respond to for me - and others - to consider what he has to say. I have always liked that aspect of the IETF that we are here as individuals, not as representatives of an organisation (although not all individuals are equal when it comes to such matters as consensus calls:-). So what I witness here is a lively discussion of the merits of two different approaches to a problem, interesting but not one that impacts me directly. Were the IETF run on different lines, perhaps I would be witnessing two silverbacks toughing it out; but it isn't, so I am not, just a lively discussion involving, inter alia, the authors of two individual I-Ds. Perhaps there will be a call for the adoption of one or both I-Ds in which case I will consider the question some more, but in the meantime, I shall track the discussion with interest. Tom Petch > > Emily Postnews would recommend a signature, eg: > > Reshmi Prem > Shrub Tree Networks > "The true voice of the operator" > > > > Illya: > > ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. As > > long as you don't do anything what other specification forbids, do you > > need to describe every possible combination of features that could be > > used together? Today you can use ADD-PATH to send multiple PATHs, > > tomorrow there will be another solution to do it. NH SAFI neither > > forbids nor requires you to use any other BGP feature beyond what's > > specified in the drafts, so by all means if you want multiple best PATHs > > from RR-client perspective you can combine NH SAFI with ADD-PATH. If you > > don't need multiple paths, you just don't use multiple paths. Do you > > feel this combination should be explicitly spelled in the NH SAFI specs? > > >>>>>>>>>>>>>>> You are talking about using ADD-PATH to choose a select > > no. of paths based only on admin costs that are statically specified on > > the PE. This needs some work or integration or extension or whatever you > > call it, to ADD-PATH. You need to mention this in your draft. > > ok, implicit assumption is that RR will use a) cost provided by RR-c; b) > > if RR-c cost is unavailable for whatever reason RR will use its own > > cost. Note that original idea is that RR-c informs RR about all costs. > > If network policies call for non-IGP preference, then RR-c can use > > ever-increasing numbers calculated in a way operator prefers. First N > > (number of preferred exits) can be explicitly configured on RR-c, the > > rest RR-c will calculate itself by ordering IGP costs of remaining > > exits. To give an example: a PE prefers NH5 and NH9, which operator > > configures on the PE manually. Let's say at some moment _all_ prefixes > > are reachable via set of next-hops NH1,NH2,...,NH50. PE sends following > > info to RR: first it tells that NH5:cost1, NH9:cost2 (because it > > configured by operator), then PE takes remaining next-hops and arranges > > them in order of increasing IGP cost behind first two next-hops, the > > cost reported for NH-i to RR is the position of that NH-i in the just > > created list. When IGP cost to non-preferred next-hops changes (due to > > topology change), PE just re-evaluates NH order and sends updated cost > > to RR. When preferred ASBR's are not available as feasible path to > > certain prefix, RR just uses whatever is next NH in the list received > > from RR-c but only for prefixes where preferred ASBR is not feasible > > exit. When preferred ASBR's fail (i.e. no path can be reached via them), > > RR uses for whatever is next NH in the list received from RR-c for all > > prefixes. So in general, when certain prefix cannot be reached via > > preferred ASBR's (regardless of the reason) then RR uses next NH in the > > list received from RR-c. If for some reason connectivity from RR-c to > > ASBR fails, RR-c will inform RR that particular NH is no longer feasible > > (as described in NH SAFI draft) and RR will stop considering that ASBR > > when calculating routes for given RR-c (even if from RR perspective or > > from any other router perspective that very same ASBR is still > > reachable). Same question as above - do you feel such behaviour should > > be explicitly spelled out even though it's natural? > > >>>>>>>>>>>>>>>>I am lost sorry. Simple example: network has 10 ASBRs. > > PE1 says ASBR1=METRIC15 and ASBR2=METRIC20 and sends this info to the > > RR. Now RR reflects both these ASBR paths to PE1 with the same metrics? > > >>>>>>>>>>>>>>>>>>>>PE1 automatically calculates IGP Cost to ASBR 3--10? > > >>>>>>>>>>>>>>>>>>>>>>> Assume ASBR 3-10 have metrics as follows > > ASBR3=3, ASBR4=4 .....ASBR10=10, This can happen right? > > >>>>>>>>>>>>>>>>>>>>>>>>>> RR advertises ASBR 3 TO ASBR 10 paths to PE1? > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does RR ensure that non candidate > > (preferred paths) are not announced to the PE upfront? > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How do you ensure that non candidate > > paths always have a higher metric than candidate paths? > > - Prem > > > > --- On *Fri, 6/10/11, Ilya Varlashkin //* wrote: > > > > > > From: Ilya Varlashkin > > Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection > > To: "Reshmi Prem" > > Cc: "raszuk@cisco.com Raszuk" , "Vinod Joseph" > > , gaurav.thareja@gmail.com, > > bruno.decraene@orange-ftgroup.com, Chintan.Shah@colt.net, "IETF IDR" > > > > Date: Friday, June 10, 2011, 2:04 PM > > > > On Jun 10, 2011, at 19:21 , Reshmi Prem wrote: > > > > > Ilya, > > > > > > I did not see your draft specifying that you would be using > > ADD-PATH, Can you confirm this? > > > > > > > ehrm...use of ADD-PATH is not feature of NH SAFI, but of...ADD-PATH. > > As long as you don't do anything what other specification forbids, > > do you need to describe every possible combination of features that > > could be used together? Today you can use ADD-PATH to send multiple > > PATHs, tomorrow there will be another solution to do it. NH SAFI > > neither forbids nor requires you to use any other BGP feature beyond > > what's specified in the drafts, so by all means if you want multiple > > best PATHs from RR-client perspective you can combine NH SAFI with > > ADD-PATH. If you don't need multiple paths, you just don't use > > multiple paths. Do you feel this combination should be explicitly > > spelled in the NH SAFI specs? > > > > > Vinod's draft specifies a means of using an RR specific RT to > > permit a RR calculated best path in addition to RTC specified paths. > > How does your draft handle this? What happens if the list of ASBRS > > that i indicate a metric for disappear?? > > > > ok, implicit assumption is that RR will use a) cost provided by > > RR-c; b) if RR-c cost is unavailable for whatever reason RR will use > > its own cost. Note that original idea is that RR-c informs RR about > > all costs. If network policies call for non-IGP preference, then > > RR-c can use ever-increasing numbers calculated in a way operator > > prefers. First N (number of preferred exits) can be explicitly > > configured on RR-c, the rest RR-c will calculate itself by ordering > > IGP costs of remaining exits. To give an example: a PE prefers NH5 > > and NH9, which operator configures on the PE manually. Let's say at > > some moment _all_ prefixes are reachable via set of next-hops > > NH1,NH2,...,NH50. PE sends following info to RR: first it tells that > > NH5:cost1, NH9:cost2 (because it configured by operator), then PE > > takes remaining next-hops and arranges them in order of increasing > > IGP cost behind first two next-hops, the cost reported for NH-i to > > RR is the position of that NH-i in the just created list. When IGP > > cost to non-preferred next-hops changes (due to topology change), PE > > just re-evaluates NH order and sends updated cost to RR. When > > preferred ASBR's are not available as feasible path to certain > > prefix, RR just uses whatever is next NH in the list received from > > RR-c but only for prefixes where preferred ASBR is not feasible > > exit. When preferred ASBR's fail (i.e. no path can be reached via > > them), RR uses for whatever is next NH in the list received from > > RR-c for all prefixes. So in general, when certain prefix cannot be > > reached via preferred ASBR's (regardless of the reason) then RR uses > > next NH in the list received from RR-c. If for some reason > > connectivity from RR-c to ASBR fails, RR-c will inform RR that > > particular NH is no longer feasible (as described in NH SAFI draft) > > and RR will stop considering that ASBR when calculating routes for > > given RR-c (even if from RR perspective or from any other router > > perspective that very same ASBR is still reachable). Same question > > as above - do you feel such behaviour should be explicitly spelled > > out even though it's natural? > > > > Kind regards, > > iLya > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Wed Jun 15 02:56:12 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3467411E8074 for ; Wed, 15 Jun 2011 02:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXjlsaFDwVyp for ; Wed, 15 Jun 2011 02:56:11 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id F338F11E8070 for ; Wed, 15 Jun 2011 02:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4622; q=dns/txt; s=iport; t=1308131771; x=1309341371; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=V91bxmZtCByinxbMyHNAVwXsbDz1rvhF0gEEQKSDDCc=; b=jqcmcKETtkhCSja6DzBD6u/kPxaozx44TuzYIcNTYh6t2SoLMCRkCONa z6Y3v6nnkftURzZV+QNtIgX6uBYk6iOEmhILyFa2oyMJ71J96Y7aKWPaL cVXjoZVt8wiW1FSc6qPEVT41USDGwBOY2NiYESzHZVVpX0DRu9atdsmQV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFABOB+E2Q/khL/2dsb2JhbAA2AQEal1qOM0R3iHOgAoMPDwGNXBwBjSuDLIJ6BJFOhFuEQoZV X-IronPort-AV: E=Sophos;i="4.65,369,1304294400"; d="scan'208";a="35309429" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 15 Jun 2011 09:56:08 +0000 Received: from [10.21.107.246] (sjc-vpnasa-1014.cisco.com [10.21.107.246]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5F9u55Z021031; Wed, 15 Jun 2011 09:56:06 GMT Message-ID: <4DF881B5.5020308@cisco.com> Date: Wed, 15 Jun 2011 11:56:05 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "t.petch" References: <243870.49492.qm@web37903.mail.mud.yahoo.com> <4DF620D2.1020203@cisco.com> <000b01cc2b30$e485cba0$4001a8c0@gateway.2wire.net> In-Reply-To: <000b01cc2b30$e485cba0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:56:12 -0000 Hi Tom, > An interesting request but not one that I think Reshmi need respond to for me - > and others - to consider what he has to say. I have always liked that aspect of > the IETF that we are here as individuals, not as representatives of an > organisation (although not all individuals are equal when it comes to such > matters as consensus calls:-). I do too. But to the extend of _real_ individuals. Here I suspect we are dealing with ghost or virtual one - hence my kind request for a bit more clarification. So since now you are putting me on the spot let me clarify what triggered my request for a bit of more insight from Mr Prem. First and above all as you perhaps know me I always try to understand everyone's points of view. Clearly I do not agree with all of them no matter who the src is and in those cases I really want to understand it better. For example the resistance from adding few new IBGP sessions in the network where policy routing is top priority was something I wanted to better understand. I was ready to visit this operator to listen about concerns to add few more sessions. However Mr Prem presented himself as: Date: Fri, 10 Jun 2011 03:42:57 -0700 (PDT) * "As an opertor I am interested in the best solution" Date: Fri, 10 Jun 2011 05:36:09 -0700 (PDT) * "Its policy that we would not like to have that kind of meshiness. I am sure you would not argue about the policy of an operator." Date: Fri, 10 Jun 2011 05:59:46 -0700 (PDT) * "Policies are always not about operations and management. There are other reasons as well. I am sure you will hear about our specific needs or have already heard from your account teams. ... Robert, understand that operators are unique in some sense or the other. So dont start becoming the advocate on how an operator should define needs or which needs are reasonable." Date: Fri, 10 Jun 2011 06:18:36 -0700 (PDT) * "I am not arguing about whether you are the messiah of a revolution in BGP Route Reflection or not." We also see a Vinod and Reshim dialog going on example: --- Date: Fri, 10 Jun 2011 21:28:38 +0100 Hi Prem, Your question on path selection on the local PE will be elaborated in the following version of the draft to be released shortly. Regards Vinod Joseph Professional Services - Service Provider Europe Juniper Networks M: +44 (0) 7500 835 876 E: vjoseph at juniper.net --- SRC: http://www.ietf.org/mail-archive/web/idr/current/maillist.html So one of my co-authors of the associated draft as well as myself poke around to find out what kind of operator that is especially since he was sending emails via yahoo. And here are a bit of shocking facts: ------ Received: from [66.129.224.36] by web37907.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 10:21:09 PDT ... Date: Fri, 10 Jun 2011 10:21:09 -0700 (PDT) From: Reshmi Prem ------ Now let's see where the source of the email (66.129.224.36) originates: $ host 66.129.224.36 36.224.129.66.in-addr.arpa domain name pointer natint3.juniper.net. ^^^^^^^^^^^^^^^^^^^^ More info ... ============= Vinod Joseph as the author which tried to submit a parallel proposal to an already accepted as IDR WG doc draft-ietf-idr-bgp-optimal-route-reflection "Reshmi Prem" email headers: Received from [66.129.224.36] by web37907.mail.mud.yahoo.com via HTTP; ^^^^^^^^^^^^^ Fri, 10 2011 Jun 10:21:09 PDT #nslookup 66.129.224.36 Name: natint3.juniper.net Address: 66.129.224.36 Vinod Joseph's email header comes from computer behind the same Juniper internal NAT: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) ^^^^^^^^^^^^^ While I do have more data at the moment IMHO this already provides sufficient basis to just ask for a bit of more clarification considering that the draft-vinod is a Juniper's draft with 4 (at the time of review) Juniper employees listed in it's ack section. People are working very hard to deliver specifications and solutions to help the Internet community via various working groups in the IETF. IETF is the organization based on trust. How can we really continue to use the trust model if vendors like Juniper Networks are using such technics to fight against competing and technically superior while much more simple solutions on the table ? Isn't this a direct departure from industry ethics we are used to ? Sincerely yours, Robert Raszuk Cisco Systems. From ietfc@btconnect.com Wed Jun 15 07:11:21 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227A29E8016 for ; Wed, 15 Jun 2011 07:11:21 -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, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zR9ilUFelHc for ; Wed, 15 Jun 2011 07:11:20 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2D69E8014 for ; Wed, 15 Jun 2011 07:11:18 -0700 (PDT) Received: from host81-156-207-154.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.154]) by c2beaomr09.btconnect.com with SMTP id DGM56703; Wed, 15 Jun 2011 15:11:09 +0100 (BST) Message-ID: <01d401cc2b5d$6469a5e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: <243870.49492.qm@web37903.mail.mud.yahoo.com> <4DF620D2.1020203@cisco.com> <000b01cc2b30$e485cba0$4001a8c0@gateway.2wire.net> <4DF881B5.5020308@cisco.com> Date: Wed, 15 Jun 2011 15:08:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4DF8BD7D.003C, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.15.130617:17:7.586, ip=81.156.207.154, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __STOCK_PHRASE_24, __FRAUD_CONTACT_NAME, ECARD_KNOWN_DOMAINS, __FRAUD_CONTACT_ADDY_B, __CP_URI_IN_BODY, __INT_PROD_COMP, __PHISH_SPEAR_ACCOUNT_1, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4DF8BD82.00D5,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: IETF IDR Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:11:21 -0000 ---- Original Message ----- From: "Robert Raszuk" To: "t.petch" Cc: "Reshmi Prem" ; "IETF IDR" Sent: Wednesday, June 15, 2011 11:56 AM > Hi Tom, > > > An interesting request but not one that I think Reshmi need respond to for me - > > and others - to consider what he has to say. I have always liked that aspect of > > the IETF that we are here as individuals, not as representatives of an > > organisation (although not all individuals are equal when it comes to such > > matters as consensus calls:-). > > I do too. But to the extend of _real_ individuals. Here I suspect we are > dealing with ghost or virtual one - hence my kind request for a bit more > clarification. > > So since now you are putting me on the spot let me clarify what > triggered my request for a bit of more insight from Mr Prem. > > First and above all as you perhaps know me I always try to understand > everyone's points of view. Clearly I do not agree with all of them no > matter who the src is and in those cases I really want to understand it > better. For example the resistance from adding few new IBGP sessions in > the network where policy routing is top priority was something I wanted > to better understand. I was ready to visit this operator to listen about > concerns to add few more sessions. > > However Mr Prem presented himself as: > > Date: Fri, 10 Jun 2011 03:42:57 -0700 (PDT) > * "As an opertor I am interested in the best solution" > > Date: Fri, 10 Jun 2011 05:36:09 -0700 (PDT) > * "Its policy that we would not like to have that kind of meshiness. I > am sure you would not argue about the policy of an operator." > > Date: Fri, 10 Jun 2011 05:59:46 -0700 (PDT) > * "Policies are always not about operations and management. There are > other reasons as well. I am sure you will hear about our specific > needs or have already heard from your account teams. > ... > Robert, understand that operators are unique in some sense or the > other. So dont start becoming the advocate on how an operator should > define needs or which needs are reasonable." > > Date: Fri, 10 Jun 2011 06:18:36 -0700 (PDT) > * "I am not arguing about whether you are the messiah of a revolution in > BGP Route Reflection or not." > > We also see a Vinod and Reshim dialog going on example: > > --- > Date: Fri, 10 Jun 2011 21:28:38 +0100 > Hi Prem, > > Your question on path selection on the local PE will be elaborated in > the following version of the draft to be released shortly. > > Regards > Vinod Joseph > Professional Services - Service Provider Europe > Juniper Networks > > M: +44 (0) 7500 835 876 > E: vjoseph at juniper.net > --- > > SRC: http://www.ietf.org/mail-archive/web/idr/current/maillist.html > > So one of my co-authors of the associated draft as well as myself poke > around to find out what kind of operator that is especially since > he was sending emails via yahoo. And here are a bit of shocking facts: > > ------ > Received: from [66.129.224.36] by web37907.mail.mud.yahoo.com via HTTP; > Fri, 10 Jun 2011 10:21:09 PDT > ... > Date: Fri, 10 Jun 2011 10:21:09 -0700 (PDT) > From: Reshmi Prem > ------ > > Now let's see where the source of the email (66.129.224.36) originates: > > $ host 66.129.224.36 > 36.224.129.66.in-addr.arpa domain name pointer natint3.juniper.net. > ^^^^^^^^^^^^^^^^^^^^ > More info ... > ============= > > Vinod Joseph as the author which tried to submit a parallel proposal to > an already accepted as IDR WG doc > draft-ietf-idr-bgp-optimal-route-reflection > > "Reshmi Prem" email headers: > > Received from [66.129.224.36] by web37907.mail.mud.yahoo.com via HTTP; > ^^^^^^^^^^^^^ Fri, 10 2011 Jun 10:21:09 PDT > > #nslookup 66.129.224.36 > Name: natint3.juniper.net > Address: 66.129.224.36 > > Vinod Joseph's email header comes from computer behind the same Juniper > internal NAT: > > from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) > ^^^^^^^^^^^^^ > > While I do have more data at the moment IMHO this already provides > sufficient basis to just ask for a bit of more clarification considering > that the draft-vinod is a Juniper's draft with 4 (at the time of review) > Juniper employees listed in it's ack section. Well, yes and no. I too look at e-mail headers and had seen Received: from [66.129.224.36] by web37906.mail.mud.yahoo.com via HTTP; Fri, 10 Jun 2011 07:30:26 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.304355 Date: Fri, 10 Jun 2011 07:30:26 -0700 (PDT) From: Reshmi Prem whereas in another context I had seen Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTW1XlrXkI3ebz3G6wQl+AOhm/6CWIlwG@postini.com; Tue, 01 Mar 2011 12:31:20 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 1 Mar 2011 12:08:49 -0800 .. Date: Tue, 1 Mar 2011 14:45:38 -0500 From: Phil Shafer ie both 66.129.224.36, both the same silverback. And this is what some organisations do, or at least allow, multiple posts from different e-mail addresses whereas with other organisations, there is one voice speaking, or at least one e-mail address (perhaps with many bodies behind it:-) It matters when it gets to rough consensus, that the chairs and AD can spot ringers and stooges, make allowances for them when evaluating the opinions expressed and, in my experience, they do. And it helps to get to meetings and see the body in question as you do, and of late, I have not; e-mail is such an impoverished channel and so hard to form judgements over. I think that the right technical solution depends on the requirements and the latter are often undefined which makes the former not clear cut. Prem hints at a different set of requirements which may make the other solution preferable, but that can only come about if his requirements are clearly stated and if those requirements are widespread, neither of which is currently true. So I see no case for that I-D to be adopted; but, it is possible that that changes. Tom Petch > People are working very hard to deliver specifications and solutions to > help the Internet community via various working groups in the IETF. IETF > is the organization based on trust. How can we really continue to use > the trust model if vendors like Juniper Networks are using such technics > to fight against competing and technically superior while much more > simple solutions on the table ? Isn't this a direct departure from > industry ethics we are used to ? > > Sincerely yours, > Robert Raszuk > Cisco Systems. From paul@jakma.org Wed Jun 15 14:21:19 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CC011E80F9 for ; Wed, 15 Jun 2011 14:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCeHxp2XDw20 for ; Wed, 15 Jun 2011 14:21:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCD311E80EA for ; Wed, 15 Jun 2011 14:21:10 -0700 (PDT) Received: by wyb29 with SMTP id 29so699933wyb.31 for ; Wed, 15 Jun 2011 14:21:10 -0700 (PDT) Received: by 10.216.221.14 with SMTP id q14mr177506wep.49.1308172869991; Wed, 15 Jun 2011 14:21:09 -0700 (PDT) Received: from [188.74.116.251] ([188.74.116.251]) by mx.google.com with ESMTPS id w62sm496976wec.18.2011.06.15.14.21.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2011 14:21:08 -0700 (PDT) Date: Wed, 15 Jun 2011 22:21:05 +0100 (BST) From: Paul Jakma To: iLya In-Reply-To: <166EA90143404A4CB7D7BC62D578B963@hnivarlas1> Message-ID: References: <5DD781A4BE13384A900438DF0608972C063BE390@emailemea4.jnpr.net> <4DEF2027.5080605@cisco.com> <5DD781A4BE13384A900438DF0608972C069970CA@emailemea4.jnpr.net> <4DEF791B.6090500@cisco.com> <5DD781A4BE13384A900438DF0608972C069970E1@emailemea4.jnpr.net> <166EA90143404A4CB7D7BC62D578B963@hnivarlas1> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: idr@ietf.org, Laurent.Lavallee@sns.bskyb.com, Vinod Joseph , raszuk@cisco.com, Amit.Khopkar@sns.bskyb.com, Chintan.Shah@colt.net, Gaurav.Thareja@colt.net Subject: Re: [Idr] more on draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:21:19 -0000 On Wed, 8 Jun 2011, iLya wrote: > we've already shown multiple times that calculating SPF for N sources to > K destinations can be done using single SPF run instead of N runs. Is that a single SPF run of comparable computational complexity (i.e. O(mlogn)? It seems very unlikely you've achieved this, but it's very big news if you have.. regards, -- Paul Jakma paul@jakma.org Key ID: 64A2FF6A Fortune: It would be nice to be sure of anything the way some people are of everything. From wwwrun@rfc-editor.org Thu Jun 16 08:44:13 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387ED21F84BC for ; Thu, 16 Jun 2011 08:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAYOrklGeaqJ for ; Thu, 16 Jun 2011 08:44:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id BFDA721F84BB for ; Thu, 16 Jun 2011 08:44:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 10EE698C4F6; Thu, 16 Jun 2011 08:44:12 -0700 (PDT) To: yakov@juniper.net, tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20110616154412.10EE698C4F6@rfc-editor.org> Date: Thu, 16 Jun 2011 08:44:12 -0700 (PDT) X-Mailman-Approved-At: Thu, 16 Jun 2011 08:56:07 -0700 Cc: idr@ietf.org, jamtaylo@cisco.com, rfc-editor@rfc-editor.org Subject: [Idr] [Technical Errata Reported] RFC4271 (2838) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 15:44:13 -0000 The following errata report has been submitted for RFC4271, "A Border Gateway Protocol 4 (BGP-4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=2838 -------------------------------------- Type: Technical Reported by: Jamie Taylor Section: 8.2.2 Original Text ------------- on page 72, description of the Established state: If the HoldTimer_Expires event occurs (Event 10), the local system: ...[list of actions to take]... Corrected Text -------------- If the HoldTimer_Expires event occurs (Event 10), the local system: - deletes all routes associated with this connection ...[list of actions in original text]... Notes ----- All other transitions from Established to Idle explicitly state that all routes associated with the connection are deleted. This transition should as well. 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. -------------------------------------- RFC4271 (draft-ietf-idr-bgp4-26) -------------------------------------- Title : A Border Gateway Protocol 4 (BGP-4) Publication Date : January 2006 Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From tony.li@tony.li Thu Jun 16 18:08:12 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3895D11E80CF for ; Thu, 16 Jun 2011 18:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj4GH59kkm0K for ; Thu, 16 Jun 2011 18:08:11 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8375011E80CC for ; Thu, 16 Jun 2011 18:08:11 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta10.emeryville.ca.mail.comcast.net with comcast id wowp1g0011u4NiLAAp89vA; Fri, 17 Jun 2011 01:08:09 +0000 Received: from [10.155.35.71] ([128.107.239.233]) by omta21.emeryville.ca.mail.comcast.net with comcast id wp781g00t52qHCY8hp7ByZ; Fri, 17 Jun 2011 01:07:33 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <20110616154412.10EE698C4F6@rfc-editor.org> Date: Thu, 16 Jun 2011 18:07:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110616154412.10EE698C4F6@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1084) Cc: skh@nexthop.com, idr@ietf.org, yakov@juniper.net, jamtaylo@cisco.com, shares@ndzh.com Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (2838) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 01:08:12 -0000 This errata seems valid to me. Other opinions? Regards, Tony On Jun 16, 2011, at 8:44 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC4271, > "A Border Gateway Protocol 4 (BGP-4)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D2838 >=20 > -------------------------------------- > Type: Technical > Reported by: Jamie Taylor >=20 > Section: 8.2.2 >=20 > Original Text > ------------- > on page 72, description of the Established state: >=20 >=20 >=20 > If the HoldTimer_Expires event occurs (Event 10), the local system: >=20 > ...[list of actions to take]... >=20 > Corrected Text > -------------- > If the HoldTimer_Expires event occurs (Event 10), the local system: >=20 > - deletes all routes associated with this connection >=20 > ...[list of actions in original text]... >=20 >=20 >=20 > Notes > ----- > All other transitions from Established to Idle explicitly state that = all routes associated with the connection are deleted. This transition = should as well. >=20 > 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.=20 >=20 > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From pauldotwall@gmail.com Thu Jun 16 22:40:57 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7FE21F8489 for ; Thu, 16 Jun 2011 22:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtstPWyj82ZU for ; Thu, 16 Jun 2011 22:40:57 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3190821F847E for ; Thu, 16 Jun 2011 22:40:57 -0700 (PDT) Received: by pzk5 with SMTP id 5so1690453pzk.31 for ; Thu, 16 Jun 2011 22:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h/lTdQV3Cqg+a5lZAIfwiDcJvZL6cfYwcZrtVi1DqpM=; b=wGGT97JKB9k0ycL4OBPwaX4EI56kieW7IRbxC3pDrP0II6SPLOS1j4bhrgj07Dtoiz 1Uskm/pfDUZTysw/Cy+asWwBR56mLQAHDfUShW6zQfNbx4f7+b+j1ew/N9AlFnlk2+WI DV3e2uvqnZG+apJiKutqINdCUXr/uM/o18OFU= 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; b=MhxwXTMi05JX0bJDGaQjsjO/jS480qkaY0xUT1ZmTCxqauoL0XPqZ5mf9OkL9PkhBi eg0DLugcQiasQHNR0ruFdbhIj+Kw8M/A8nUrqqfzOFpZ7snuM3tCImhBphJ861TDDT6O HK/cqLj+gdntMWdp2u2dmZEE2rrZwdKOCsbWg= MIME-Version: 1.0 Received: by 10.68.27.103 with SMTP id s7mr886700pbg.246.1308289256717; Thu, 16 Jun 2011 22:40:56 -0700 (PDT) Received: by 10.68.48.229 with HTTP; Thu, 16 Jun 2011 22:40:56 -0700 (PDT) In-Reply-To: <4DF881B5.5020308@cisco.com> References: <243870.49492.qm@web37903.mail.mud.yahoo.com> <4DF620D2.1020203@cisco.com> <000b01cc2b30$e485cba0$4001a8c0@gateway.2wire.net> <4DF881B5.5020308@cisco.com> Date: Thu, 16 Jun 2011 22:40:56 -0700 Message-ID: From: Paul WALL To: raszuk@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 05:40:57 -0000 On Wed, Jun 15, 2011 at 2:56 AM, Robert Raszuk wrote: > People are working very hard to deliver specifications and solutions to help > the Internet community via various working groups in the IETF. IETF is the > organization based on trust. How can we really continue to use the trust > model if vendors like Juniper Networks are using such technics to fight > against competing and technically superior while much more simple solutions > on the table ? Isn't this a direct departure from industry ethics we are > used to ? In the interest of transparency, Cisco is guilty of performing similar shenanigans. Its a well known fact that Cisco encourages its customers to chime in on IETF drafts, even when the some of the customers staff has no comprehension of what is at hand. For example look at the amount of posts from a certain large Cisco customer in support of something. Note that all the emails came in roughly within a few days of each other. # RE: Advancing the Protocol and Morin Drafts, SZELA, MATEUSZ W (MATT), ATTLABS # RE: Advancing the Protocol and Morin Drafts, RAMSAROOP, JEEWAN P, ATTLABS # RE: Advancing the Protocol and Morin Drafts, ROSENBERG, ERIC, ATTLABS # RE: Advancing the Protocol and Morin Drafts, SUNDT, MARK R, ATTLABS # RE: Advancing the Protocol and Morin Drafts, RAMACHANDRAN, PRASANNA, ATTOPS # RE: Advancing the Protocol and Morin Drafts, ASIF, SAUD, ATTLABS # RE: Advancing the Protocol and Morin Drafts, DUBOSE, KENNETH S (KEN), ATTOPS and again this time pushing the aigp draft all within a few days: # Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document - Support, ZATLOUKAL, JAMES W (JIM), ATTOPS # Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document, SAAD, SAMIR S, ATTLABS # [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document, KARIM, REHAN, ATTLABS # [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document, GIBBONS, JOHN, ATTLABS # Re: [Idr] draft-rosen-idr-aigp-00.txt, PULIPATI, RAVI, ATTLABS # Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document, TONG, HUI, ATTLABS These aren't common names you see actively participating in the IETF meetings or on the mailing lists. Its pretty obvious what is going on here. Drive Slow, Paul WALL From randy@psg.com Fri Jun 17 06:34:52 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B83011E80E2 for ; Fri, 17 Jun 2011 06:34:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyhkqEpkSPCZ for ; Fri, 17 Jun 2011 06:34:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 066B311E8070 for ; Fri, 17 Jun 2011 06:34:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QXZAy-000GYI-2g; Fri, 17 Jun 2011 13:33:32 +0000 Date: Fri, 17 Jun 2011 06:33:31 -0700 Message-ID: From: Randy Bush To: Paul WALL In-Reply-To: References: <243870.49492.qm@web37903.mail.mud.yahoo.com> <4DF620D2.1020203@cisco.com> <000b01cc2b30$e485cba0$4001a8c0@gateway.2wire.net> <4DF881B5.5020308@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: raszuk@cisco.com, IETF IDR Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 13:34:52 -0000 > In the interest of transparency, Cisco is guilty of performing similar > shenanigans. Its a well known fact that Cisco encourages its customers > to chime in on IETF drafts, even when the some of the customers staff > has no comprehension of what is at hand. i think of it more as friends giving the one man dos attack a break. randy From jgs@juniper.net Fri Jun 17 08:18:27 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0103911E81BF for ; Fri, 17 Jun 2011 08:18:26 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4y8dX96B7Kl for ; Fri, 17 Jun 2011 08:18:26 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 450EC11E81B1 for ; Fri, 17 Jun 2011 08:18:25 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTftwQOB4BwQbFAOb95QxxUw43JF9tKDe@postini.com; Fri, 17 Jun 2011 08:18:26 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 17 Jun 2011 08:15:29 -0700 From: John Scudder To: "idr@ietf.org List" Date: Fri, 17 Jun 2011 08:15:28 -0700 Thread-Topic: self-identification in email Thread-Index: AcwtAWSIiKz/I1ZHTeeIvNkaRDBfqA== Message-ID: <5A814C3B-2F9D-43A0-8EE2-A40D2D805F65@juniper.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 Subject: [Idr] self-identification in email X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:18:27 -0000 Folks, In connection with the recent discussion, Sue and I as chairs would like to= make clear that we expect posts to the IDR mailing list will be made openl= y and transparently. Obviously we all use different email addresses from t= ime to time, but please make sure you help everyone know who you are by sig= ning your name at the bottom of every email. (If you feel the need to post= without attribution, you can send your message to a chair or AD to be anon= ymized.) As Sue has said before, "Life is long" so kindness and civility creates a I= DR-world where we can solve Internet problems we need to solve.=20 --Sue and John From jgs@juniper.net Fri Jun 17 08:19:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2D911E81C2 for ; Fri, 17 Jun 2011 08:18:59 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF-2htMYXOCH for ; Fri, 17 Jun 2011 08:18:59 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6A52B11E81B1 for ; Fri, 17 Jun 2011 08:18:58 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTftwYQhpFzBv8NE7D7jGGaUblq3tYwsK@postini.com; Fri, 17 Jun 2011 08:18:58 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 17 Jun 2011 08:16:28 -0700 From: John Scudder To: "idr@ietf.org List" Date: Fri, 17 Jun 2011 08:16:27 -0700 Thread-Topic: self-identification in email, bis Thread-Index: AcwtAYfGD9z6C8RUQsyaGlHKmawXwg== Message-ID: 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 Subject: [Idr] self-identification in email, bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:19:00 -0000 I will add in my capacity as a Juniper employee that Juniper is investigati= ng the "Prem" posts and will take whatever action may be appropriate. It's= Juniper's policy that employees identify themselves accurately in their pu= blic postings. Thanks, --John (with WG co-chair hat off)= From mn1921@att.com Fri Jun 17 09:00:38 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB43C21F84A8 for ; Fri, 17 Jun 2011 09:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAPbmL5vwxRA for ; Fri, 17 Jun 2011 09:00:38 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id E8EAA21F84A6 for ; Fri, 17 Jun 2011 09:00:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1308326436!23261726!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27829 invoked from network); 17 Jun 2011 16:00:37 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jun 2011 16:00:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5HFxS87021752; Fri, 17 Jun 2011 11:59:29 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5HFxKAR021585; Fri, 17 Jun 2011 11:59:23 -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: Fri, 17 Jun 2011 12:00:24 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A20094D92FF@misout7msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection Thread-Index: AcwssS0csny+uPX/TriV60qd8nlWkgAVcGbw References: <243870.49492.qm@web37903.mail.mud.yahoo.com><4DF620D2.1020203@cisco.com><000b01cc2b30$e485cba0$4001a8c0@gateway.2wire.net><4DF881B5.5020308@cisco.com> From: "NAPIERALA, MARIA H (ATTSI)" To: "Paul WALL" , X-Mailman-Approved-At: Fri, 17 Jun 2011 09:20:59 -0700 Cc: IETF IDR Subject: Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:00:38 -0000 >=20 > For example look at the amount of posts from a certain large Cisco > customer in support of something. Note that all the emails came in > roughly within a few days of each other. >=20 > # RE: Advancing the Protocol and Morin Drafts, SZELA, MATEUSZ W (MATT), > ATTLABS > # RE: Advancing the Protocol and Morin Drafts, RAMSAROOP, JEEWAN P, > ATTLABS > # RE: Advancing the Protocol and Morin Drafts, ROSENBERG, ERIC, ATTLABS > # RE: Advancing the Protocol and Morin Drafts, SUNDT, MARK R, ATTLABS > # RE: Advancing the Protocol and Morin Drafts, RAMACHANDRAN, PRASANNA, > ATTOPS > # RE: Advancing the Protocol and Morin Drafts, ASIF, SAUD, ATTLABS > # RE: Advancing the Protocol and Morin Drafts, DUBOSE, KENNETH S (KEN), > ATTOPS To set the record straight - Cisco had nothing to do with this voting.=20 Please be careful what you state about the people who voted above as not having a "comprehension of what is at hand". Not only that they clearly identified themselves but they work directly on MVPNs either in the design or operations. They possess more "comprehension" on the subject at hand than you can imagine ;-). Please check your facts before you made such disrespectful accusations.. Maria Napierala AT&T Labs From wwwrun@rfc-editor.org Fri Jun 17 09:52:19 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5911E81E6; Fri, 17 Jun 2011 09:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC5zraAo4+Cm; Fri, 17 Jun 2011 09:52:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 407A411E81F4; Fri, 17 Jun 2011 09:52:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 335C798C50B; Fri, 17 Jun 2011 09:52:18 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110617165218.335C798C50B@rfc-editor.org> Date: Fri, 17 Jun 2011 09:52:18 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 6286 on Autonomous-System-Wide Unique BGP Identifier for BGP-4 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:52:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6286 Title: Autonomous-System-Wide Unique BGP Identifier for BGP-4 Author: E. Chen, J. Yuan Status: Standards Track Stream: IETF Date: June 2011 Mailbox: enkechen@cisco.com, jenny@cisco.com Pages: 4 Characters: 7497 Updates: RFC4271 I-D Tag: draft-ietf-idr-bgp-identifier-14.txt URL: http://www.rfc-editor.org/rfc/rfc6286.txt To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System-wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271. [STANDARDS-TRACK] This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From raszuk@cisco.com Fri Jun 17 11:39:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2B21F8525 for ; Fri, 17 Jun 2011 11:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoI-UiAErN8Y for ; Fri, 17 Jun 2011 11:39:38 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9D421F8522 for ; Fri, 17 Jun 2011 11:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1513; q=dns/txt; s=iport; t=1308335978; x=1309545578; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=MCX4potyzccJZoHKUimBanRcxNYLIktPvjSo7GMGbwA=; b=EUJ7HQZnbCVzIWPVvjYI30lzEXsxKA1Ttequ6UCeECBiw0O5DQAH0pmW XXFu5cbzJrDVP6c/fo8EzMX0ZLNh3OWm/NPRqSzWYYgtMTgEqd9Dirf/1 11Zj4eeqNLoUrOQal1ZZoJElMmBV+MNNF6UBClKSQ2+NES54B9go9kh53 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUIADWe+02rRDoG/2dsb2JhbABSmAiOSHeIc6Bzgw8PAZpbhicEkV6EX4sg X-IronPort-AV: E=Sophos;i="4.65,382,1304294400"; d="scan'208";a="379343148" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 17 Jun 2011 18:39:38 +0000 Received: from [10.21.108.210] ([10.21.108.210]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5HIdbr5027440 for ; Fri, 17 Jun 2011 18:39:37 GMT Message-ID: <4DFB9F6B.4000002@cisco.com> Date: Fri, 17 Jun 2011 20:39:39 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: idr@ietf.org References: <5A814C3B-2F9D-43A0-8EE2-A40D2D805F65@juniper.net> In-Reply-To: <5A814C3B-2F9D-43A0-8EE2-A40D2D805F65@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] self-identification in email X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:39:39 -0000 Hi John, While I do encourage open discussion I wonder how are you going to enforce that the name used to sign an email is a _real_ name of an operator, vendor, student or cheerleader as opposed to a non existent just made up ghost name ? That is I think the root cause of the issue not that there is no name signature at the bottom of the email. Moreover ... when I read notes from any IETF WG meeting ... I see no way to send unicast clarification/exploration question to the name behind any statement. Could IDR enforce that meeting minutes contain the email address of the folks who spoke at the microphone ? Not that hard considering that it is already on the blue sheet. Thx, R. > Folks, > > In connection with the recent discussion, Sue and I as chairs would > like to make clear that we expect posts to the IDR mailing list will > be made openly and transparently. Obviously we all use different > email addresses from time to time, but please make sure you help > everyone know who you are by signing your name at the bottom of every > email. (If you feel the need to post without attribution, you can > send your message to a chair or AD to be anonymized.) > > As Sue has said before, "Life is long" so kindness and civility > creates a IDR-world where we can solve Internet problems we need to > solve. > > --Sue and John _______________________________________________ Idr > mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > From randy@psg.com Fri Jun 17 12:12:06 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B459E8031 for ; Fri, 17 Jun 2011 12:12:06 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XechAltGuE5P for ; Fri, 17 Jun 2011 12:12:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id E5DF09E800A for ; Fri, 17 Jun 2011 12:12:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QXeSW-000H9r-Tm; Fri, 17 Jun 2011 19:12:01 +0000 Date: Fri, 17 Jun 2011 12:12:00 -0700 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4DFB9F6B.4000002@cisco.com> References: <5A814C3B-2F9D-43A0-8EE2-A40D2D805F65@juniper.net> <4DFB9F6B.4000002@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] self-identification in email X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 19:12:06 -0000 making a bunch of rules will not stop social disfunction. one thing we might try is restricting ourselves to one or two messages a day. randy From ietfc@btconnect.com Sat Jun 18 04:43:47 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6BB11E8096 for ; Sat, 18 Jun 2011 04:43:47 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7F-PC50nOp0 for ; Sat, 18 Jun 2011 04:43:46 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0C811E8082 for ; Sat, 18 Jun 2011 04:43:45 -0700 (PDT) Received: from host81-156-207-154.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.154]) by c2bthomr14.btconnect.com with SMTP id DGI06840; Sat, 18 Jun 2011 12:43:35 +0100 (BST) Message-ID: <00e901cc2da4$4465a3e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Tony Li" , "RFC Errata System" References: <20110616154412.10EE698C4F6@rfc-editor.org> Date: Sat, 18 Jun 2011 12:41:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DFC8F66.00D1, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.18.105715:17:7.586, ip=81.156.207.154, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4DFC8F68.00AA,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: skh@nexthop.com, idr@ietf.org, jamtaylo@cisco.com, shares@ndzh.com, yakov@juniper.net Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (2838) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 11:43:47 -0000 ----- Original Message ----- From: "Tony Li" To: "RFC Errata System" Cc: ; ; ; ; Sent: Friday, June 17, 2011 3:07 AM Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (2838) > This errata seems valid to me. Other opinions? > > Regards, > Tony The deletion of routes was added to the FSM between draft-idr-bgp4-17 and draft-idr-bgp4-18. Sue was making the changes and this one was triggered by an e-mail in January 2002 from Alex Zinin. His e-mail explicitly calls out the changes and has deletion of routes for some events and not for others, when in the Established state. I never got to find out why he proposed it (at all - for myself, I would have left it as part of the catchall 'releases all BGP resources'). Tom Petch > > On Jun 16, 2011, at 8:44 AM, RFC Errata System wrote: > > > > > The following errata report has been submitted for RFC4271, > > "A Border Gateway Protocol 4 (BGP-4)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=2838 > > > > -------------------------------------- > > Type: Technical > > Reported by: Jamie Taylor > > > > Section: 8.2.2 > > > > Original Text > > ------------- > > on page 72, description of the Established state: > > > > > > > > If the HoldTimer_Expires event occurs (Event 10), the local system: > > > > ...[list of actions to take]... > > > > Corrected Text > > -------------- > > If the HoldTimer_Expires event occurs (Event 10), the local system: > > > > - deletes all routes associated with this connection > > > > ...[list of actions in original text]... > > > > > > > > Notes > > ----- > > All other transitions from Established to Idle explicitly state that all routes associated with the connection are deleted. This transition should as well. > > > > 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. > > > > -------------------------------------- > > RFC4271 (draft-ietf-idr-bgp4-26) > > -------------------------------------- > > Title : A Border Gateway Protocol 4 (BGP-4) > > Publication Date : January 2006 > > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > > Category : DRAFT STANDARD > > Source : Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Mon Jun 20 05:45:24 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218A711E815E for ; Mon, 20 Jun 2011 05:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orFy9-G-kyIf for ; Mon, 20 Jun 2011 05:45:23 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 61FB011E8092 for ; Mon, 20 Jun 2011 05:45:22 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTf9A3ZfI3LvRAy6ZhaRc2jRQGVUygpgC@postini.com; Mon, 20 Jun 2011 05:45:23 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 20 Jun 2011 05:41:17 -0700 From: John Scudder To: t.petch Date: Mon, 20 Jun 2011 05:41:14 -0700 Thread-Topic: [Idr] [Technical Errata Reported] RFC4271 (2838) Thread-Index: AcwvR1i5Edyyt90TT/6T7ITUTC/Afg== Message-ID: References: <20110616154412.10EE698C4F6@rfc-editor.org> <00e901cc2da4$4465a3e0$4001a8c0@gateway.2wire.net> In-Reply-To: <00e901cc2da4$4465a3e0$4001a8c0@gateway.2wire.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 Cc: "skh@nexthop.com" , "idr@ietf.org" , Yakov Rekhter , Tony Li , "jamtaylo@cisco.com" , "shares@ndzh.com" , RFC Errata System Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (2838) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:45:24 -0000 I agree, but given that the other transitions from Established do explicitl= y call out route deletion for whatever reason, it makes sense to me that it= be made consistent. --John On Jun 18, 2011, at 6:41 AM, t.petch wrote: > ----- Original Message ----- > From: "Tony Li" > To: "RFC Errata System" > Cc: ; ; ; > ; > Sent: Friday, June 17, 2011 3:07 AM > Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (2838) >=20 >=20 >> This errata seems valid to me. Other opinions? >>=20 >> Regards, >> Tony >=20 > The deletion of routes was added to the FSM between > draft-idr-bgp4-17 and draft-idr-bgp4-18. > Sue was making the changes and this one was triggered by an e-mail in Jan= uary > 2002 > from Alex Zinin. His e-mail explicitly calls out the changes and has del= etion > of routes for > some events and not for others, when in the Established state. I never g= ot to > find out > why he proposed it (at all - for myself, I would have left it as part of = the > catchall > 'releases all BGP resources'). >=20 > Tom Petch >=20 >=20 >=20 >=20 >=20 >>=20 >> On Jun 16, 2011, at 8:44 AM, RFC Errata System wrote: >>=20 >>>=20 >>> The following errata report has been submitted for RFC4271, >>> "A Border Gateway Protocol 4 (BGP-4)". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D2838 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Jamie Taylor >>>=20 >>> Section: 8.2.2 >>>=20 >>> Original Text >>> ------------- >>> on page 72, description of the Established state: >>>=20 >>>=20 >>>=20 >>> If the HoldTimer_Expires event occurs (Event 10), the local system: >>>=20 >>> ...[list of actions to take]... >>>=20 >>> Corrected Text >>> -------------- >>> If the HoldTimer_Expires event occurs (Event 10), the local system: >>>=20 >>> - deletes all routes associated with this connection >>>=20 >>> ...[list of actions in original text]... >>>=20 >>>=20 >>>=20 >>> Notes >>> ----- >>> All other transitions from Established to Idle explicitly state that al= l > routes associated with the connection are deleted. This transition shoul= d as > well. >>>=20 >>> 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. >>>=20 >>> -------------------------------------- >>> RFC4271 (draft-ietf-idr-bgp4-26) >>> -------------------------------------- >>> Title : A Border Gateway Protocol 4 (BGP-4) >>> Publication Date : January 2006 >>> Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. >>> Category : DRAFT STANDARD >>> Source : Inter-Domain Routing >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Mon Jun 20 05:53:04 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DABD11E8168 for ; Mon, 20 Jun 2011 05:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz2hpEn-4scq for ; Mon, 20 Jun 2011 05:53:03 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 79A9511E8092 for ; Mon, 20 Jun 2011 05:53:03 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTf9Crp2nofjJHxDA6LQ3QS75kscAK1oy@postini.com; Mon, 20 Jun 2011 05:53:03 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 20 Jun 2011 05:52:38 -0700 From: John Scudder To: "idr@ietf.org List" Date: Mon, 20 Jun 2011 05:52:36 -0700 Thread-Topic: Pending errata for RFC 4271 Thread-Index: AcwvSO8wltDiNQUSQB2fILtm+WrvmA== Message-ID: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.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 Subject: [Idr] Pending errata for RFC 4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:53:04 -0000 While reviewing the latest erratum I noticed that we actually have four of = them sitting in "reported" state: http://www.rfc-editor.org/errata_search.php?rfc=3D4271&rec_status=3D2&prese= ntation=3Drecords In reviewing these I think they all seem fine, although erratum 150 should = be marked as editorial, not technical. The oldest of these is more than five years old! I believe the procedure t= o get these marked "verified" is for the chairs to ask the IESG to do it. = Unless there is an objection by the Tuesday June 28, I'll plan to do that. Thanks, --John= From tony.li@tony.li Mon Jun 20 07:24:38 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A5621F84AB for ; Mon, 20 Jun 2011 07:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mubOGlsEWxpl for ; Mon, 20 Jun 2011 07:24:37 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1F12B21F84AA for ; Mon, 20 Jun 2011 07:24:37 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta14.emeryville.ca.mail.comcast.net with comcast id yCpp1g0031bwxycAEEQbZn; Mon, 20 Jun 2011 14:24:35 +0000 Received: from sjc-vpn3-955.cisco.com ([128.107.239.233]) by omta18.emeryville.ca.mail.comcast.net with comcast id yEQv1g00152qHCY8eEQyQW; Mon, 20 Jun 2011 14:25:04 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.net> Date: Mon, 20 Jun 2011 07:24:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] Pending errata for RFC 4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:24:38 -0000 On Jun 20, 2011, at 5:52 AM, John Scudder wrote: > While reviewing the latest erratum I noticed that we actually have = four of them sitting in "reported" state: >=20 > = http://www.rfc-editor.org/errata_search.php?rfc=3D4271&rec_status=3D2&pres= entation=3Drecords >=20 > In reviewing these I think they all seem fine, although erratum 150 = should be marked as editorial, not technical. >=20 > The oldest of these is more than five years old! I believe the = procedure to get these marked "verified" is for the chairs to ask the = IESG to do it. Unless there is an objection by the Tuesday June 28, = I'll plan to do that. I concur. Thanks John! Tony From ietfc@btconnect.com Mon Jun 20 08:35:42 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276469E801A for ; Mon, 20 Jun 2011 08:35:42 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na1X+HVsoV5c for ; Mon, 20 Jun 2011 08:35:39 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 31CF79E802A for ; Mon, 20 Jun 2011 08:35:38 -0700 (PDT) Received: from host81-156-207-154.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.154]) by c2bthomr13.btconnect.com with SMTP id DHG96879; Mon, 20 Jun 2011 16:35:35 +0100 (BST) Message-ID: <00fb01cc2f57$007aa680$4001a8c0@gateway.2wire.net> From: "t.petch" To: "John Scudder" , References: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.net> Date: Mon, 20 Jun 2011 16:32:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DFF68C7.0021, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.20.143314:17:7.586, ip=81.156.207.154, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_1100_1199, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4DFF68C7.0133,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [Idr] Pending errata for RFC 4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:35:42 -0000 Erratum 1332 would add 'Unsupported Capability' to the Open Error subcodes but this functionality and error code does not appear anywhere in RFC 4271 (or RFC 1771) so I think that this Erratum should be rejected. As IANA records, this error subcode is defined in RFC5492/RFC3392 Tom Petch ----- Original Message ----- From: "John Scudder" To: Sent: Monday, June 20, 2011 2:52 PM Subject: [Idr] Pending errata for RFC 4271 > While reviewing the latest erratum I noticed that we actually have four of them sitting in "reported" state: > > http://www.rfc-editor.org/errata_search.php?rfc=4271&rec_status=2&presentation=r ecords > > In reviewing these I think they all seem fine, although erratum 150 should be marked as editorial, not technical. > > The oldest of these is more than five years old! I believe the procedure to get these marked "verified" is for the chairs to ask the IESG to do it. Unless there is an objection by the Tuesday June 28, I'll plan to do that. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Mon Jun 20 09:17:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2EA1F0C5E for ; Mon, 20 Jun 2011 09:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRiBx1P7tjOE for ; Mon, 20 Jun 2011 09:17:48 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 46D791F0C5B for ; Mon, 20 Jun 2011 09:17:48 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTf9yqja5LlhaBOydVwpWKp0xNTvOgQlF@postini.com; Mon, 20 Jun 2011 09:17:48 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 20 Jun 2011 09:16:10 -0700 From: John Scudder To: t.petch Date: Mon, 20 Jun 2011 09:16:07 -0700 Thread-Topic: [Idr] Pending errata for RFC 4271 Thread-Index: AcwvZV1XTVmMgKwSSvW66CLTmKqZKg== Message-ID: <6E3C5A04-E38A-485D-B9C5-53CAD14D5CD0@juniper.net> References: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.net> <00fb01cc2f57$007aa680$4001a8c0@gateway.2wire.net> In-Reply-To: <00fb01cc2f57$007aa680$4001a8c0@gateway.2wire.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 Cc: "idr@ietf.org" Subject: Re: [Idr] Pending errata for RFC 4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:17:50 -0000 True enough. =20 Any dissenters? --John On Jun 20, 2011, at 10:32 AM, t.petch wrote: > Erratum 1332 would add 'Unsupported Capability' to the Open Error subcode= s but > this functionality and error code does not appear anywhere in RFC 4271 (o= r RFC > 1771) so I think that this Erratum should be rejected. >=20 > As IANA records, this error subcode is defined in RFC5492/RFC3392 >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "John Scudder" > To: > Sent: Monday, June 20, 2011 2:52 PM > Subject: [Idr] Pending errata for RFC 4271 >=20 >=20 >> While reviewing the latest erratum I noticed that we actually have four = of > them sitting in "reported" state: >>=20 >>=20 > http://www.rfc-editor.org/errata_search.php?rfc=3D4271&rec_status=3D2&pre= sentation=3Dr > ecords >>=20 >> In reviewing these I think they all seem fine, although erratum 150 shou= ld be > marked as editorial, not technical. >>=20 >> The oldest of these is more than five years old! I believe the procedur= e to > get these marked "verified" is for the chairs to ask the IESG to do it. = Unless > there is an objection by the Tuesday June 28, I'll plan to do that. >>=20 >> Thanks, >>=20 >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 From tony.li@tony.li Mon Jun 20 09:28:19 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD051F0C6B for ; Mon, 20 Jun 2011 09:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sIhMxFGoPaU for ; Mon, 20 Jun 2011 09:28:18 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 82EA41F0C6A for ; Mon, 20 Jun 2011 09:28:18 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id yGSw1g00D1YDfWL52GUGVt; Mon, 20 Jun 2011 16:28:16 +0000 Received: from sjc-vpn3-955.cisco.com ([128.107.239.233]) by omta20.westchester.pa.mail.comcast.net with comcast id yGTz1g01J52qHCY3gGU3DR; Mon, 20 Jun 2011 16:28:12 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li X-Priority: 3 In-Reply-To: <00fb01cc2f57$007aa680$4001a8c0@gateway.2wire.net> Date: Mon, 20 Jun 2011 09:27:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <552BB225-AEC5-4812-8812-ABEAEAB5911D@tony.li> References: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.net> <00fb01cc2f57$007aa680$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] Pending errata for RFC 4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:28:19 -0000 On Jun 20, 2011, at 7:32 AM, t.petch wrote: > Erratum 1332 would add 'Unsupported Capability' to the Open Error = subcodes but > this functionality and error code does not appear anywhere in RFC 4271 = (or RFC > 1771) so I think that this Erratum should be rejected. >=20 > As IANA records, this error subcode is defined in RFC5492/RFC3392 True, but it would leave the list of subcodes in 4271 incomplete. =20 You may (correctly) argue that the only definitive list should be = maintained by IANA, and thus the ultimately correct approach would be to = withdraw the lists of errors from section 4.5 and reference the IANA = registry, and leave the initial list of errors in the IANA = considerations section. This seems like a much larger change. I = believe that the errata is a fine tradeoff in ensuring that others are = aware of the additional code point. Tony From jgs@juniper.net Mon Jun 20 09:36:21 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A15511E809B for ; Mon, 20 Jun 2011 09:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgtvBs-eqI0p for ; Mon, 20 Jun 2011 09:36:20 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 85AAA11E8087 for ; Mon, 20 Jun 2011 09:36:20 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTf93Av38Uc3IhdY0dUkbTRB0v3/AIGaz@postini.com; Mon, 20 Jun 2011 09:36:20 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 20 Jun 2011 09:32:36 -0700 From: John Scudder To: Tony Li Date: Mon, 20 Jun 2011 09:32:34 -0700 Thread-Topic: [Idr] Pending errata for RFC 4271 Thread-Index: AcwvZ6mEtma7OgyASmuMeIcUOsqcUA== Message-ID: <31E9F278-0862-4559-AD38-26FAFD620E88@juniper.net> References: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.net> <00fb01cc2f57$007aa680$4001a8c0@gateway.2wire.net> <552BB225-AEC5-4812-8812-ABEAEAB5911D@tony.li> In-Reply-To: <552BB225-AEC5-4812-8812-ABEAEAB5911D@tony.li> 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 Cc: "idr@ietf.org" Subject: Re: [Idr] Pending errata for RFC 4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:36:21 -0000 On Jun 20, 2011, at 12:27 PM, Tony Li wrote: > On Jun 20, 2011, at 7:32 AM, t.petch wrote: >=20 >> Erratum 1332 would add 'Unsupported Capability' to the Open Error subcod= es but >> this functionality and error code does not appear anywhere in RFC 4271 (= or RFC >> 1771) so I think that this Erratum should be rejected. >>=20 >> As IANA records, this error subcode is defined in RFC5492/RFC3392 >=20 >=20 > True, but it would leave the list of subcodes in 4271 incomplete. =20 >=20 > You may (correctly) argue that the only definitive list should be maintai= ned by IANA, and thus the ultimately correct approach would be to withdraw = the lists of errors from section 4.5 and reference the IANA registry, and l= eave the initial list of errors in the IANA considerations section. This s= eems like a much larger change. I believe that the errata is a fine tradeo= ff in ensuring that others are aware of the additional code point. I essentially agree with both. The IANA registry is indisputably the autho= rity. OTOH the erratum doesn't hurt and might help. I am, therefore, not = terribly bothered either way (and have now expended more than my quota of t= yping messages about this very nitty nit). Consensus as of next Tuesday ta= kes it, with "accept the erratum" being the default in case of no clear con= sensus. (Right now we're in the "accept it" column.) --John= From ietfc@btconnect.com Mon Jun 20 10:30:21 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1321F8523 for ; Mon, 20 Jun 2011 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqhH9DP5KRkY for ; Mon, 20 Jun 2011 10:30:17 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id F1B3E21F8513 for ; Mon, 20 Jun 2011 10:30:14 -0700 (PDT) Received: from host81-156-207-154.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.154]) by c2bthomr07.btconnect.com with SMTP id DMA37038; Mon, 20 Jun 2011 18:30:08 +0100 (BST) Message-ID: <017001cc2f67$01121140$4001a8c0@gateway.2wire.net> From: "t.petch" To: "John Scudder" , "Tony Li" References: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.net> <00fb01cc2f57$007aa680$4001a8c0@gateway.2wire.net> <552BB225-AEC5-4812-8812-ABEAEAB5911D@tony.li> <31E9F278-0862-4559-AD38-26FAFD620E88@juniper.net> Date: Mon, 20 Jun 2011 18:27:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DFF839F.0102, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.20.161215:17:7.586, ip=81.156.207.154, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_1900_1999, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4DFF83A1.00A4,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: idr@ietf.org Subject: Re: [Idr] Pending errata for RFC 4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 17:30:21 -0000 ----- Original Message ----- From: "John Scudder" To: "Tony Li" Cc: "t.petch" ; Sent: Monday, June 20, 2011 6:32 PM On Jun 20, 2011, at 12:27 PM, Tony Li wrote: > On Jun 20, 2011, at 7:32 AM, t.petch wrote: > >> Erratum 1332 would add 'Unsupported Capability' to the Open Error subcodes but >> this functionality and error code does not appear anywhere in RFC 4271 (or RFC >> 1771) so I think that this Erratum should be rejected. >> >> As IANA records, this error subcode is defined in RFC5492/RFC3392 > > > True, but it would leave the list of subcodes in 4271 incomplete. > > You may (correctly) argue that the only definitive list should be maintained by IANA, and thus the ultimately correct approach would be to withdraw the lists of errors from section 4.5 and reference the IANA registry, and leave the initial list of errors in the IANA considerations section. This seems like a much larger change. I believe that the errata is a fine tradeoff in ensuring that others are aware of the additional code point. I essentially agree with both. The IANA registry is indisputably the authority. OTOH the erratum doesn't hurt and might help. I am, therefore, not terribly bothered either way (and have now expended more than my quota of typing messages about this very nitty nit). Consensus as of next Tuesday takes it, with "accept the erratum" being the default in case of no clear consensus. (Right now we're in the "accept it" column.) John At the risk of all the problems that come with 'e-mail quota exceeded' .... You need to make it clear to IANA that this functional change to an IANA Considerations MUST NOT cause them to change anything because what they have now is correct, and what they would have had had this erratum been included as it stands in RFC4271 would have been incorrect:-) (I favour leaving sleepng dogs lie) Tom Petch --John= From internet-drafts@ietf.org Thu Jun 23 07:23:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380EB9E8051; Thu, 23 Jun 2011 07:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjNqt0pFHYjY; Thu, 23 Jun 2011 07:23:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47F29E8047; Thu, 23 Jun 2011 07:23:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110623142335.7363.67332.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2011 07:23:35 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 14:23:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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) : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-06.txt Pages : 14 Date : 2011-06-23 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 decis= ions 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-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-aigp-06.txt From enkechen@cisco.com Mon Jun 27 17:06:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B04811E8070 for ; Mon, 27 Jun 2011 17:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geY5s-KjH5S6 for ; Mon, 27 Jun 2011 17:06:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 12A2A9E8005 for ; Mon, 27 Jun 2011 17:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=102100; q=dns/txt; s=iport; t=1309219599; x=1310429199; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=iap+hlnuQBj98juThAgrreN3IlRvoEkHqeNqk/TyINY=; b=Fr/pzXhHDJFJkbne/4QO979Zic8zbBNM/XPtdVsMgkVeOwxFLs9QPvyA w7UIqGI9fYgRAxOe/oIMRs6GtTy8eYkWxTSKv06C2VE+M0RLT8i59xJH8 Q+ZD8ckyB3f3d5UDSdvGMMHjqc/ecB3hGg04LLjX585AgLRn2PkFhEGoH 8=; X-Files: draft-ietf-idr-rfc4893bis-04.txt : 24813 X-IronPort-AV: E=Sophos;i="4.65,435,1304294400"; d="txt'?scan'208,217";a="387314123" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2011 00:06:38 +0000 Received: from enkechen-mac.local ([10.155.35.248]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5S06c8B013343; Tue, 28 Jun 2011 00:06:38 GMT Message-ID: <4E091B54.4090008@cisco.com> Date: Mon, 27 Jun 2011 17:07:48 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: John Leslie References: <20101018152745.GT82074@verdi> In-Reply-To: <20101018152745.GT82074@verdi> Content-Type: multipart/mixed; boundary="------------040004070001000606070709" Cc: "quaizar.vohra@gmail.com" , idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-rfc4893bis-03.txt, BGP Support for Four-octet AS Number Space X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 00:06:45 -0000 This is a multi-part message in MIME format. --------------040004070001000606070709 Content-Type: multipart/alternative; boundary="------------010806050506040507080202" --------------010806050506040507080202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, John: Thanks a lot for your thorough review, and sorry for the long delay in getting back. I have made quite a few editorial changes based on your suggestions. However, there are also a few changes that do not seem necessary, and have been left out. Given the maturity of the technology and the late stage of the document, I think that we should try to maintain the consistency with RFC 4893, and limit the changes to the ones that are really required. Please take a look at the attached draft. If there are no major issues, I will submit it in two weeks. -- Enke On 10/18/10 8:27 AM, John Leslie wrote: > > John Scudder wrote: > > > > This is to start a working group last call on > > draft-ietf-idr-rfc4893bis-03.txt, BGP Support for Four-octet > > AS Number Space. Please send any comments to the list. > > Please send your comments by Monday, October 18. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-03.txt > > As threatened: ;^) > > ] Abstract > ] > ] Currently the Autonomous System (AS) number is encoded as a two-octet > ] entity in BGP. > > Delete (outdated and unneeded) > > ] This document describes extensions to BGP to carry the > ] Autonomous System number as a four-octet entity. > > (This is a sufficient Abstract.) > > ] 1. Introduction > ] > ] Currently the Autonomous System number is encoded as a two-octet > ] entity in BGP [RFC4271]. > > Replace with > " > " In the base BGP specification [RFC4271] the Autonomous System number > " is encoded as a two-octet entity. > > ] To prepare for the anticipated exhaustion of the two-octet AS numbers, > > Delete (outdated) and replace with > " > " With 32-bit AS numbers being allocated by registries, > > ] this document describes extensions to > ] BGP to carry the Autonomous System number as a four-octet entity. > ^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^^ > Replace with plural: > " > " Autonomous System numbers > > ] More specifically, this document defines > ] a new BGP capability, Four-octet AS Number Capability, > ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Delete "new"; use IANA name "Support for 4-octet AS number capability" > > ] that can be used by a BGP speaker to indicate its support... > ^^^^ ^^^ ^^ ^^^^ > Replace with "to be used" > > ] Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced... > ^^^ > Delete "new". > > ] 2. Specification of Requirements > > Rename as "Definitions"; add the following: > " > " 16-bit AS number > " An Autonomous System number in the range 0-65535, as assigned by IANA > " in the "16-bit Autonomous System Numbers" registry. > " > " 32-bit AS number > " An Autonomous System number in the range 65535-4294967295, as assigned > " by IANA in the "32-bit Autonomous System Numbers" registry. > " > " AS_TRANS > " The 16-bit AS number assigned by IANA as a placeholder for 32-bit AS > " numbers which don't fit in the base BGP spec. > " > " 2-octet AS number > " The representation of AS numbers as defined in the BGP spec [RFC4271]. > " > " 4-octet AS number > " The representation of AS numbers as defined in this document for NEW > " BGP speakers, using 4 octets to hold a 32-bit unsigned number, with > " high-order octets coming first. > " > " NEW BGP speaker > " A BGP speaker that implements this specification and uses 4-octet > " representation of AS numbers for sessions with other NEW BGP speakers. > " > " OLD BGP speaker > " A BGP speaker that does not implement this specification, and MAY > " carry 4-octet AS numbers (without being aware of them) in Optional > " Transitive attributes defined in this specification. > > ] 3. Protocol Extensions > ] > ] For the purpose of this document we define a BGP speaker that does > ] not support the new 4-octet AS number extensions as an OLD BGP > ] speaker, and a BGP speaker that supports the new 4-octet AS number > ] extensions as a NEW BGP speaker. > > Delete this paragraph (covered in Definitions). > > ] BGP carries the Autonomous System number in the... > ^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^^ > Change to plural (there isn't only one AS number). > > ] NEW BGP speakers carry AS path information expressed in terms of 4- > ] octet Autonomous Systems numbers by using the existing AS_PATH > ] attribute, except that each AS number in this attribute is encoded > ] not as a 2-octet, but as a 4-octet entity. > > Reword to clarify: > " > " BGP sessions between NEW BGP speakers carry AS path information with > " 4-octet AS numbers in the AS_PATH attribute (instead of 2-octet AS > " numbers as specified in [RFC4271]). > > ] The same applies to the > ] AGGREGATOR attribute - NEW BGP speakers use the same attribute, > ] except that the AS carried in this attribute is encoded as a 4-octet > ] entity. > > No change. > > Add before the next paragraph: > " > " For sessions between a NEW BGP speaker and an OLD BGP speaker, > " AS_PATH and AGGREGATOR attributes will continue to contain 2-octet > " AS numbers as specified in [RFC4271]. > > ] To preserve AS path information with 4-octet AS numbers across OLD... > ^^^^^^^ > Replace with "32-bit". > > ] The AS4_PATH attribute has > ] the same semantics as the AS_PATH attribute, except that it is > ] optional transitive, and it carries 4-octet AS numbers. > ^ > Add at end of sentence > " > " and certain components of an AS_PATH are prohibited > > ] To prevent the possible propagation of confederation path segments > ] outside of a confederation, the path segment types AS_CONFED_SEQUENCE > ] and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH > ] attribute, and MUST NOT be carried in an UPDATE message. > ^^^^ ^^^ ^^ ^^^^^^^ ^^ ^^ ^^^^^^ ^^^^^^^ > Replace with > " > " MUST NOT be included in an AS4_PATH attribute sent in an UPDATE > " message from a NEW BGP speaker to an OLD BGP speaker, even though > " they are present in the AS_PATH attribute sent in that UPDATE. > > (I may have misunderstood this, but I can't read 4893-bis any other > way.) > > ] Similarly, this document defines a new aggregator attribute called > ] AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR > ] attribute has the same semantics as the AGGREGATOR attribute, except > ] that it carries a 4-octet AS number. > > No change. > > ] Currently assigned 2-octet Autonomous System numbers are converted > ] into 4-octet Autonomous System numbers by setting the two high-order > ] octets of the 4-octet field to zero. Such a 4-octet AS number is > ] said to be mappable to a 2-octet AS number. > > Delete. (covered elsewhere; the "mappable" concept won't be needed) > > ] To represent 4-octet AS numbers (which are not mapped from 2-octets) > ] as 2-octet AS numbers in the AS path information encoded with 2-octet > ] AS numbers, this document reserves a 2-octet AS number. We denote > ] this special AS number as AS_TRANS for ease of description in the > ] rest of this specification. > > Replace with > " > " To represent 32-bit AS numbers in a BGP session between a NEW BGP > " speaker and an OLD BGP speaker, IANA has reserved the AS number > " "AS_TRANS". It is used (as a 2-octet AS number) wherever a 32-bit AS > " number would otherwise overflow the 2-octet AS number representation > " in an AS_PATH or AGGREGATOR attribute in an UPDATE sent by a NEW BGP > " speaker to an OLD BGP speaker. > > ] This AS number is also placed in the "My Autonomous System" field of > ] the OPEN message originated by a NEW BGP speaker, if the speaker > ] does not have a (globally unique) 2-octet AS number. > ^^^^^^^ > Replace with "16-bit" > > ] 4. Operations > ] 4.1. Interaction Between NEW BGP Speakers > ] > ] A BGP speaker that supports 4-octet Autonomous System numbers SHOULD > ^^^^^^ > Replace with MUST. > > (IMHO, if it doesn't advertise it it MUST behave exactly as an OLD > BGP speaker, so it doesn't fit our definition of NEW BGP speaker.) > > ] advertise this to its peers using the BGP Capability Advertisements. > ] The Autonomous System number of the BGP speaker MUST be carried in > ] the capability value field of the advertised capability. > ^^^^^^^^^^ > Replace with "Support for 4-octet AS number" (IANA's name for it) > > ] When a NEW BGP speaker processes an OPEN message from another NEW BGP > ] speaker, it MUST use the Autonomous System number encoded in the > ] Capability Value field of the Capability in lieu of the "My > ] Autonomous System" field of the OPEN message. > > No change (though it wouldn't hurt to repeat the IANA capability name) > > ] A BGP speaker that advertises such capability to a particular peer, > ] and receives from that peer the advertisement of such capability MUST > > Change to > " > " A NEW BGP speaker that receives the Support for 4-octet AS number > " capability from a peer MUST > > ] encode Autonomous System numbers as 4-octet entities in both the > ] AS_PATH and the AGGREGATOR attributes in the updates it sends to the > ] peer, and MUST assume that these attributes in the updates received > ] from the peer encode Autonomous System numbers as 4-octet entities. > > No change. > > ] The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried > ] in an UPDATE message between NEW BGP speakers. A NEW BGP speaker > ] that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute > ] in an UPDATE message from another NEW BGP speaker MUST discard the > ] path attribute and continue processing the UPDATE message. > > No change. > > ] 4.2. Interaction Between NEW and OLD BGP Speakers > ] 4.2.1. BGP Peering > ] > ] Note that peering between a NEW BGP speaker and an OLD one is > ] possible only if the NEW BGP speaker has a 2-octet AS number. > ^^^ ^ ^^^^^^^ > Change to "uses a 16-bit" > > ] However, this document does not assume that an Autonomous System with > ] NEW speakers has to have a globally unique 2-octet AS number -- > ] AS_TRANS could be used instead (even if a multiple Autonomous System > ] would use it). > > Change to > " > " A NEW BGP speaker which hasn't been assigned a 16-bit AS number will > " still send OPEN messages to peers which may be OLD BGP speakers, > " using AS_TRANS as the AS number in the OPEN message. > " > " This might lead to confusion if the OLD BGP speaker peers with two or > " more Autonomous Systems which have not been assigned 16-bit AS numbers. > " Since the OLD BGP speaker will necessarily be unaware of this issue, > " a NEW BGP speaker MAY pre-emptively close a session to an OLD BGP > " speaker if this confusion is seen to be a problem. This SHOULD NOT be > " the default configuration, though. > > ] 4.2.2. Generating Updates > ] > ] When communicating with an OLD BGP speaker, a NEW speaker MUST send > ] the AS path information in the AS_PATH attribute encoded with 2-octet > ] AS numbers. The NEW speaker MUST also send the AS path information > ] in the AS4_PATH attribute (encoded with 4-octet AS numbers), except > ] for the case where the entire AS path information is composed of 2- > ] octet AS numbers only. In this case, the NEW speaker MUST NOT send > ] the AS4_PATH attribute. > > No change proposed, but I'm nervous whether this MUST NOT is > _always_ observed in the field. I'd suggest language to the effect that > an AS4_PATH containing no 32-bit AS numbers SHOULD be ignored (but that > strays into changing-bits-on-the wire territory). > > ] In the AS_PATH attribute encoded with 2-octet AS numbers, > ] non-mappable 4-octet AS numbers are represented by the well-known > ^^^^^^^^^^^^ ^^^^^^^ > Change to "32-bit" ("non-mappable" isn't needed) > > ] 2-octet AS number, AS_TRANS. > ^^^^^^^ > Replace with "16-bit" > > ] This will preserve the path length property of the AS path information > ] and also help in updating the AS path information received on a NEW > ] BGP speaker from an OLD speaker, as explained in the next section. > > I suggest deleting this. (It's no longer _entirely_ true.) > > ] The NEW speaker constructs the AS4_PATH attribute from the AS path > ] information. > > I suggest > " > " A NEW BGP speaker sending UPDATEs to an OLD BGP speaker constructs an > " AS4_PATH attribute using the same (internal) information used to > " construct the (2-octet) AS_PATH attribute. > > ] In the case where the AS path information contains > ] either AS_CONFED_SEQUENCE or AS_CONFED_SET path segments, the NEW > ] speaker, when constructing the AS4_PATH attribute from the AS path > ] information, MUST exclude such path segments. > > I suggest > " > " Wherever this information contains AS_CONFED_SEQUENCE or AS_CONFED_SET > " path segments, the NEW BGP speaker MUST exclude them from the AS4_PATH. > > (I'm not clear whether also excluding them from the AS_PATH is > permitted.) > > ] The AS4_PATH attribute > ] will be carried across a series of OLD BGP speakers without > ] modification and will help preserve the non-mappable 4-octet AS > ] numbers in the AS path information. > > I suggest > " > " The AS4_PATH attribute, being Optional Transitive, must (per [RFC4271]) > " be advertised unmodified by the OLD BGP speaker to any peer to which > " it advertises that NLRI. Thus, after passing through any number of OLD > " BGP speakers, the AS4_PATH will emerge unmodified to the first NEW > " speaker that encounters it. > > ] Similarly, if the NEW speaker has to send the AGGREGATOR attribute, > ] and if the aggregating Autonomous System's AS number is a non- > ] mappable 4-octet AS number, then the speaker MUST use the > ] AS4_AGGREGATOR attribute, and set the AS number field in the existing > ] AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that > ] if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute > ] MUST NOT be sent. > > I suggest > " > " If the NEW BGP speaker includes an AGGREGATOR attribute in an UPDATE > " to an OLD BGP speaker, it MUST check whether the aggregating AS > " number is a 32-bit AS number, and if it is it MUST also include an > " AS4_AGGREGATOR attribute with a 4-octet AS number (in addition to > " the 2-octet AS_TRANS in the AGGREGATOR attribute. > > ] 4.2.3. Processing Received Updates > ] > ] When a NEW BGP speaker receives an update from an OLD one, it should > ^^^^^^ > Replace with MUST > > ] be prepared to receive the AS4_PATH attribute along with the existing > ] AS_PATH attribute. If the AS4_PATH attribute is also received, > ^ > Add "and passes certain validity checks" > > ] both the attributes will be used to construct the exact AS path > ] information, and therefore the information carried by both the > ] attributes will be considered for AS path loop detection. > > I'd simplify > " > " the AS4_PATH attribute (and AS4_AGGREGATOR) will be used to supplement > " the AS_PATH attribute in constructing the (internal) AS path and in > " checking for AS path loops. > > ] Note that a route may have traversed a series of autonomous systems > ] with 2-octet AS numbers and OLD BGP speakers only. In that case, if > ] the route carries the AS4_PATH attribute, this attribute must have > ] remained unmodified since the route left the last NEW BGP speaker. > > I'd delete this. (I think we've covered it already.) > > ] The trailing AS path information (representing autonomous systems > ] with 2-octet AS numbers and OLD BGP speakers only) is contained only > ] in the current AS_PATH attribute (encoded in the leading part of the > ] AS_PATH attribute). > > No change. > > ] Under certain conditions, it may not be possible to reconstruct the > ] entire AS path information from the AS_PATH and the AS4_PATH > ] attributes of a route. > > I'd make this its own paragraph. > > ] This occurs > ^^^^ ^^^^^^ > Change to "For example," > > ] when two or more routes that carry the AS4_PATH attribute are > ] aggregated by an OLD BGP speaker, and the AS4_PATH attribute of > ] at least one of these routes carries at least one 4-octet AS number > ] (as oppose to a 2-octet AS number that is encoded in 4 octets). > > Change to > " If an OLD BGP speaker aggregates routes, one or more of which contain > " the (unrecognized) AS4_PATH attribute, the 32-bit AS number(s) in > " that AS4_PATH attribute will generally be lost. > > ] Depending on the implementation, either the AS4_PATH attribute would > ] be lost during route aggregation, or both the AS_PATH attribute and > ] the AS4_PATH attribute would contain valid, partial information that > ] cannot be combined seamlessly, resulting in incomplete AS path > ] information in these cases. > > No change. > > ] A NEW BGP speaker should also be prepared to receive the > ] AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an > ] OLD BGP speaker. When both the attributes are received, if the AS > ] number in the AGGREGATOR attribute is not AS_TRANS, then: > ] > ] - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL > ] be ignored, > ] - the AGGREGATOR attribute SHALL be taken as the information > ] about the aggregating node, and > ] - the AS_PATH attribute SHALL be taken as the AS path > ] information. > ] > ] Otherwise, > > ] - the AGGREGATOR attribute SHALL be ignored, > ] - the AS4_AGGREGATOR attribute SHALL be taken as the information > ] about the aggregating node, and > ] - the AS path information would need to be constructed, as in all > ] other cases. > > No change needed, but I'd suggest swapping the order (putting "if > the AS number in the AGGREGATOR attribute is AS_TRANS" first). > > ] In order to construct the AS path information, it would be necessary > ] to first calculate the number of AS numbers in the AS_PATH and > ] AS4_PATH attributes using the method specified in Section 9.1.2.2 > ] [RFC4271] and [RFC5065] for route selection. > ] > ] If the number of AS numbers in the AS_PATH attribute is less than the > ] number of AS numbers in the AS4_PATH attribute, then the AS4_PATH > ] attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken > ] as the AS path information. > ] > ] If the number of AS numbers in the AS_PATH attribute is larger than > ] or equal to the number of AS numbers in the AS4_PATH attribute, then > ] the AS path information SHALL be constructed by taking as many AS > ] numbers and path segments as necessary from the leading part of the > ] AS_PATH attribute, and then prepending them to the AS4_PATH attribute > ] so that the AS path information has an identical number of AS numbers > ] as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or > ] AS_CONFED_SET path segment SHALL be prepended if it is either the > ] leading path segment or adjacent to a path segment that is prepended. > > I don't feel able to clarify these paragraphs. Note, however, that > "Section 9.1.2.2 [RFC4271]" refers to "Breaking Ties" and may not be > the right reference. > > Also, I am not sure all implementations in the field blindly prepend > part of the AS_PATH to the AS4_PATH (though that clearly is what > RFC4893 calls for. > > Also, I frankly don't understand the last sentence about "Note that > a valid AS_CONFED_SEQUENCE...". It would be good, IMHO, to replace it > with clearer text about what happens to AS4_PATH in this case. > > ] 5. Handling BGP Communities > > No change. (But isn't RFC5668 a Normative reference?) > > Note, RFC5668 may not be implemented in all systems to which the > Extended Communities may be forwarded: I don't see a problem there, but > I may have missed one... > > ] 6. Error Handling > ] > ] The general guidelines presented in [OPT-TRANS] > > Another Normative reference... > > ] apply to the error > ] handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in > ] this document. It is noted, however, that the nature (i.e., NEW > ] speaker or OLD speaker) of a direct neighbor based on the > ] announcement of the 4-octet AS Capability allows a local speaker to > ] determine unequivocally whether the direct neighbor recognizes these > ] new attributes. Thus there is no need to examine the the attribute > ] flags (somewhat weaker indicator in this case) for that > ] determination. > > I think this is too vague: we should state clearly which flags are > to be checked. (I'm not sure what our consensus may be here.) > > Note also, that as a Normative reference, 4893bis would have to wait > for completion of draft-ietf-idr-optional-transitive before being > published. > > (BTW, the [OPT-TRANS] reference should clearly name the I-D title.) > > ] Given that the two-octet AS numbers dominate during the transition, > ] and are carried in the AS_PATH attribute by an OLD BGP speaker, in > ] this document the "attribute discard" approach is chosen to handle a > ] malformed AS4_PATH attribute. > > I think we could safely prescribe that without needing a Normative > reference... > > ] Similarly, as the AS4_AGGREGATOR is just informational, the > ] "attribute discard" approach is chosen to handle a malformed > ] AS4_AGGREGATOR attribute. > > Likewise. > > ] The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be > ] carried in an UPDATE message between NEW BGP speakers. A NEW BGP > ] speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR > ] attribute in an UPDATE message from another NEW BGP speaker MUST > ] discard the path attribute and continue processing the UPDATE > ] message. This case SHOULD be logged locally for analysis. > > No change. > > ] In addition, the path segment types AS_CONFED_SEQUENCE and > ] AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute > ] of an UPDATE message. A NEW BGP speaker that receives these path > ] segment types in the AS4_PATH attribute of an UPDATE message from an > ] OLD BGP speaker MUST discard these path segments, > > No change. > > ] adjust the relevant attribute fields accordingly, > > IMHO, this is too vague (but I don't have text to propose). > > ] and continue processing the UPDATE message. This case SHOULD be logged > ] locally for analysis. > > No change. > > ] The AS4_PATH attribute in an UPDATE message SHALL be considered > ] malformed under the following conditions: > ] > ] - the attribute length is not a multiple of two, or is too small > ] (i.e., less than 6) for the attribute to carry at least one > ] AS number, or > ] > ] - the path segment length in the attribute is either zero, or > ] is inconsistent with the attribute length, or > > No change. > > ] - the path segment type in the attribute is not one of the > ] types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE > ] and AS_CONFED_SET. > > No specific change, but I'm not clear on this: it seems to complicate > the introduction of new path segments (for all I know, there may already > be some in the wild). We have no language in 4893bis to require stripping > these when creating an AS4_PATH. > > ] A NEW BGP speaker that receives a malformed AS4_PATH attribute in an > ] UPDATE message from an OLD BGP speaker MUST discard the attribute, > ] and continue processing the UPDATE message. The error SHOULD be > ] logged locally for analysis. > ] > ] The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered > ] malformed if the attribute length is not 8. > ] > ] A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute > ] in an UPDATE message from an OLD BGP speaker MUST discard the > ] attribute, and continue processing the UPDATE message. The error > ] SHOULD be logged locally for analysis. > > No change. > > ] 7. Transition > > I think this section could be shortened. > > ] The scheme described in this document allows a gradual transition > ] from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one > ] Autonomous System or one BGP speaker at a time. > > Is this needed? > > ] To simplify transition, this document assumes that an Autonomous > ] System could start using a 4-octet AS number only after all the BGP > ] speakers within that Autonomous System have been upgraded to support > ] 4-octet AS numbers. > > Is this needed? What happens if the condition isn't met? > > ] An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System > ] number. > > Is this needed? We have no way to enforce it. > > ] A non-mappable 4-octet AS number cannot be used as a "Member AS > ] Number" of a BGP Confederation until all the BGP speakers within the > ] Confederation have transitioned to support 4-octet AS numbers. > ^^^^^^^ > Change to "32-bit" > > ] In an environment where an Autonomous System that has OLD BGP > ] speakers peers with two or more Autonomous Systems that have NEW BGP > ] speakers and use AS_TRANS (rather than having a globally unique AS > ] number), use of Multi-Exit Discriminators by the Autonomous System > ] with the OLD speakers may result in a situation where Multi-Exit > ] Discriminator will influence route selection among the routes that > ] were received from different neighboring Autonomous Systems. > > I think this says the OLD BGP speaker cannot distinguish MEDs. We > have no way to enforce any behavior on OLD speakers, so if we say > anything here, it must be about what NEW speakers would do. I don't > know what to suggest. (Is this needed?) > > ] Under certain conditions, it may not be possible to reconstruct the > ] entire AS path information from the AS_PATH and the AS4_PATH > ] attributes of a route. This occurs when two or more routes that > ] carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, > ] and the AS4_PATH attribute of at least one of these routes carries at > ] least one 4-octet AS number (as oppose to a 2-octet AS number that is > ] encoded in 4 octets). > ] When such aggregation results in creating a > ] route that is less specific than any of the component routes (route > ] whose Network Layer Reachability Information (NLRI) covers NLRI of > ] all the component routes), loss of the AS path information does not > ] create a risk of a routing loop. In all other cases, loss of the AS > ] path information does create a risk of a routing loop. > > Duplicate text, not needed here. > > ] When such aggregation results in creating a > ] route that is less specific than any of the component routes (route > ] whose Network Layer Reachability Information (NLRI) covers NLRI of > ] all the component routes), loss of the AS path information does not > ] create a risk of a routing loop. In all other cases, loss of the AS > ] path information does create a risk of a routing loop. > > If we're going to say anything about routing loops, I believe we > need to define "routing loop" and "forwarding loop"; and I'd strongly > recommend putting this in a different section. > > 8. IANA Considerations > > ] This document expands the pool for AS numbers from 0 - 65535 to 0 - > ] 4294967295. The AS numbers are managed by the IANA "Autonomous > ] System Numbers" registry. Other than expanding the AS number pool, > ] this document does not propose any modifications to the existing > ] policies and procedures pertaining to the AS number allocation. > > Delete. (already done, no IANA action needed) > > ] This document uses a BGP Capability code to indicate that a BGP > ] speaker supports the 4-octet AS numbers. The Capability Code 65 has > ] been assigned by IANA per [RFC5492]. > > No change. > > ] In addition, this document introduces two new BGP optional transitive > ] attributes, and their type codes have been assigned by the IANA. The > ] first one is the AS4_PATH attribute, value 17, which preserves the AS > ] path information with 4-octet AS numbers across old BGP speakers. > ] The second one is the AS4_AGGREGATOR attribute, value 18, which is > ] similar in use to the current AGGREGATOR attribute, but it carries a > ] 4-octet AS number. > > Delete. (already done, no IANA action needed) > > ] Finally, this document introduces a reserved 2-octet AS number -- > ^^^^^^^^^^ > Change to "describes the use of" > > ] AS_TRANS. The AS number 23456 has been assigned by the IANA for > ] AS_TRANS. > > Add: "IANA will need to update the 16-bit AS number registry to > point to this document. > > ] 9. Security Considerations > > A separate issue, not covered in this email... > > -- > John Leslie > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --------------010806050506040507080202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, John:

Thanks a lot for your thorough review, and sorry for the long delay in getting back.

I have made quite a few editorial changes based on your suggestions.  However, there are also a few changes that do not seem necessary, and have been left out.   Given the maturity of the technology and the late stage of the document, I think that we should try to maintain the consistency with RFC 4893, and limit the changes to the ones that are really required.

Please take a look at the attached draft.  If there are no major issues, I will submit it in two weeks.

-- Enke


On 10/18/10 8:27 AM, John Leslie wrote:
Re: [Idr] WGLC for draft-ietf-idr-rfc4893bis-03.txt,BGP Support for Four-octet AS Number Space

John Scudder <jgs@juniper.net> wrote:
>
> This is to start a working group last call on
> draft-ietf-idr-rfc4893bis-03.txt, BGP Support for Four-octet
> AS Number Space.  Please send any comments to the list.
> Please send your comments by Monday, October 18.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-03.txt

   As threatened:   ;^)

] Abstract
]
] Currently the Autonomous System (AS) number is encoded as a two-octet
] entity in BGP.

   Delete (outdated and unneeded)

] This document describes extensions to BGP to carry the
] Autonomous System number as a four-octet entity.

   (This is a sufficient Abstract.)

] 1. Introduction
]
] Currently the Autonomous System number is encoded as a two-octet
] entity in BGP [RFC4271].

   Replace with
"
" In the base BGP specification [RFC4271] the Autonomous System number
" is encoded as a two-octet entity.

] To prepare for the anticipated exhaustion of the two-octet AS numbers,

   Delete (outdated) and replace with
"
" With 32-bit AS numbers being allocated by registries,

] this document describes extensions to
] BGP to carry the Autonomous System number as a four-octet entity.
               ^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^^
   Replace with plural:
"
" Autonomous System numbers

] More specifically, this document defines
] a new BGP capability, Four-octet AS Number Capability,
    ^^^                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Delete "new"; use IANA name "Support for 4-octet AS number capability"

] that can be used by a BGP speaker to indicate its support...
  ^^^^ ^^^ ^^ ^^^^
   Replace with "to be used"

] Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced...
      ^^^
   Delete "new".

] 2. Specification of Requirements

   Rename as "Definitions"; add the following:
"
" 16-bit AS number
" An Autonomous System number in the range 0-65535, as assigned by IANA
" in the "16-bit Autonomous System Numbers" registry.
"
" 32-bit AS number
" An Autonomous System number in the range 65535-4294967295, as assigned
" by IANA in the "32-bit Autonomous System Numbers" registry.
"
" AS_TRANS
" The 16-bit AS number assigned by IANA as a placeholder for 32-bit AS
" numbers which don't fit in the base BGP spec.
"
" 2-octet AS number
" The representation of AS numbers as defined in the BGP spec [RFC4271].
"
" 4-octet AS number
" The representation of AS numbers as defined in this document for NEW
" BGP speakers, using 4 octets to hold a 32-bit unsigned number, with
" high-order octets coming first.
"
" NEW BGP speaker
" A BGP speaker that implements this specification and uses 4-octet
" representation of AS numbers for sessions with other NEW BGP speakers.
"
" OLD BGP speaker
" A BGP speaker that does not implement this specification, and MAY
" carry 4-octet AS numbers (without being aware of them) in Optional
" Transitive attributes defined in this specification.

] 3. Protocol Extensions
]
] For the purpose of this document we define a BGP speaker that does
] not support the new 4-octet AS number extensions as an OLD BGP
] speaker, and a BGP speaker that supports the new 4-octet AS number
] extensions as a NEW BGP speaker.

   Delete this paragraph (covered in Definitions).

] BGP carries the Autonomous System number in the...
              ^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^^
   Change to plural (there isn't only one AS number).

] NEW BGP speakers carry AS path information expressed in terms of 4-
] octet Autonomous Systems numbers by using the existing AS_PATH
] attribute, except that each AS number in this attribute is encoded
] not as a 2-octet, but as a 4-octet entity.

   Reword to clarify:
"
" BGP sessions between NEW BGP speakers carry AS path information with
" 4-octet AS numbers in the AS_PATH attribute (instead of 2-octet AS
" numbers as specified in [RFC4271]).

] The same applies to the
] AGGREGATOR attribute - NEW BGP speakers use the same attribute,
] except that the AS carried in this attribute is encoded as a 4-octet
] entity.

   No change.

   Add before the next paragraph:
"
" For sessions between a NEW BGP speaker and an OLD BGP speaker,
" AS_PATH and AGGREGATOR attributes will continue to contain 2-octet
" AS numbers as specified in [RFC4271].

] To preserve AS path information with 4-octet AS numbers across OLD...
                                       ^^^^^^^
   Replace with "32-bit".

] The AS4_PATH attribute has
] the same semantics as the AS_PATH attribute, except that it is
] optional transitive, and it carries 4-octet AS numbers.
                                                        ^
   Add at end of sentence
"
" and certain components of an AS_PATH are prohibited

] To prevent the possible propagation of confederation path segments
] outside of a confederation, the path segment types AS_CONFED_SEQUENCE
] and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH
] attribute, and MUST NOT be carried in an UPDATE message.
                 ^^^^ ^^^ ^^ ^^^^^^^ ^^ ^^ ^^^^^^ ^^^^^^^
   Replace with
"
" MUST NOT be included in an AS4_PATH attribute sent in an UPDATE
" message from a NEW BGP speaker to an OLD BGP speaker, even though
" they are present in the AS_PATH attribute sent in that UPDATE.

   (I may have misunderstood this, but I can't read 4893-bis any other
way.)

] Similarly, this document defines a new aggregator attribute called
] AS4_AGGREGATOR, which is optional transitive.  The AS4_AGGREGATOR
] attribute has the same semantics as the AGGREGATOR attribute, except
] that it carries a 4-octet AS number.

   No change.

] Currently assigned 2-octet Autonomous System numbers are converted
] into 4-octet Autonomous System numbers by setting the two high-order
] octets of the 4-octet field to zero.  Such a 4-octet AS number is
] said to be mappable to a 2-octet AS number.

   Delete. (covered elsewhere; the "mappable" concept won't be needed)

] To represent 4-octet AS numbers (which are not mapped from 2-octets)
] as 2-octet AS numbers in the AS path information encoded with 2-octet
] AS numbers, this document reserves a 2-octet AS number.  We denote
] this special AS number as AS_TRANS for ease of description in the
] rest of this specification.

   Replace with
"
" To represent 32-bit AS numbers in a BGP session between a NEW BGP
" speaker and an OLD BGP speaker, IANA has reserved the AS number
" "AS_TRANS". It is used (as a 2-octet AS number) wherever a 32-bit AS
" number would otherwise overflow the 2-octet AS number representation
" in an AS_PATH or AGGREGATOR attribute in an UPDATE sent by a NEW BGP
" speaker to an OLD BGP speaker.

] This AS number is also placed in the "My Autonomous System" field of
] the OPEN message originated by a NEW BGP speaker, if the speaker
] does not have a (globally unique) 2-octet AS number.
                                    ^^^^^^^
   Replace with "16-bit"

] 4. Operations
] 4.1. Interaction Between NEW BGP Speakers
]
] A BGP speaker that supports 4-octet Autonomous System numbers SHOULD
                                                                ^^^^^^
   Replace with MUST.

   (IMHO, if it doesn't advertise it it MUST behave exactly as an OLD
BGP speaker, so it doesn't fit our definition of NEW BGP speaker.)

] advertise this to its peers using the BGP Capability Advertisements.
] The Autonomous System number of the BGP speaker MUST be carried in
] the capability value field of the advertised capability.
                                    ^^^^^^^^^^
   Replace with "Support for 4-octet AS number" (IANA's name for it)

] When a NEW BGP speaker processes an OPEN message from another NEW BGP
] speaker, it MUST use the Autonomous System number encoded in the
] Capability Value field of the Capability in lieu of the "My
] Autonomous System" field of the OPEN message.

   No change (though it wouldn't hurt to repeat the IANA capability name)

] A BGP speaker that advertises such capability to a particular peer,
] and receives from that peer the advertisement of such capability MUST

   Change to
"
" A NEW BGP speaker that receives the Support for 4-octet AS number
" capability from a peer MUST

] encode Autonomous System numbers as 4-octet entities in both the
] AS_PATH and the AGGREGATOR attributes in the updates it sends to the
] peer, and MUST assume that these attributes in the updates received
] from the peer encode Autonomous System numbers as 4-octet entities.

   No change.

] The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried
] in an UPDATE message between NEW BGP speakers.  A NEW BGP speaker
] that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute
] in an UPDATE message from another NEW BGP speaker MUST discard the
] path attribute and continue processing the UPDATE message.

   No change.

] 4.2. Interaction Between NEW and OLD BGP Speakers
] 4.2.1. BGP Peering
]
] Note that peering between a NEW BGP speaker and an OLD one is
] possible only if the NEW BGP speaker has a 2-octet AS number.
                                       ^^^ ^ ^^^^^^^
   Change to "uses a 16-bit"

] However, this document does not assume that an Autonomous System with
] NEW speakers has to have a globally unique 2-octet AS number --
] AS_TRANS could be used instead (even if a multiple Autonomous System
] would use it).

   Change to
"
" A NEW BGP speaker which hasn't been assigned a 16-bit AS number will
" still send OPEN messages to peers which may be OLD BGP speakers,
" using AS_TRANS as the AS number in the OPEN message.
"
" This might lead to confusion if the OLD BGP speaker peers with two or
" more Autonomous Systems which have not been assigned 16-bit AS numbers.
" Since the OLD BGP speaker will necessarily be unaware of this issue,
" a NEW BGP speaker MAY pre-emptively close a session to an OLD BGP
" speaker if this confusion is seen to be a problem. This SHOULD NOT be
" the default configuration, though.

] 4.2.2. Generating Updates
]
] When communicating with an OLD BGP speaker, a NEW speaker MUST send
] the AS path information in the AS_PATH attribute encoded with 2-octet
] AS numbers.  The NEW speaker MUST also send the AS path information
] in the AS4_PATH attribute (encoded with 4-octet AS numbers), except
] for the case where the entire AS path information is composed of 2-
] octet AS numbers only.  In this case, the NEW speaker MUST NOT send
] the AS4_PATH attribute.

   No change proposed, but I'm nervous whether this MUST NOT is
_always_ observed in the field. I'd suggest language to the effect that
an AS4_PATH containing no 32-bit AS numbers SHOULD be ignored (but that
strays into changing-bits-on-the wire territory).

] In the AS_PATH attribute encoded with 2-octet AS numbers,
] non-mappable 4-octet AS numbers are represented by the well-known
  ^^^^^^^^^^^^ ^^^^^^^
   Change to "32-bit" ("non-mappable" isn't needed)

] 2-octet AS number, AS_TRANS.
  ^^^^^^^
   Replace with "16-bit"

] This will preserve the path length property of the AS path information
] and also help in updating the AS path information received on a NEW
] BGP speaker from an OLD speaker, as explained in the next section.

   I suggest deleting this. (It's no longer _entirely_ true.)

] The NEW speaker constructs the AS4_PATH attribute from the AS path
] information.

   I suggest
"
" A NEW BGP speaker sending UPDATEs to an OLD BGP speaker constructs an
" AS4_PATH attribute using the same (internal) information used to
" construct the (2-octet) AS_PATH attribute.

] In the case where the AS path information contains
] either AS_CONFED_SEQUENCE or AS_CONFED_SET path segments, the NEW
] speaker, when constructing the AS4_PATH attribute from the AS path
] information, MUST exclude such path segments.

   I suggest
"
" Wherever this information contains AS_CONFED_SEQUENCE or AS_CONFED_SET
" path segments, the NEW BGP speaker MUST exclude them from the AS4_PATH.

   (I'm not clear whether also excluding them from the AS_PATH is
permitted.)

] The AS4_PATH attribute
] will be carried across a series of OLD BGP speakers without
] modification and will help preserve the non-mappable 4-octet AS
] numbers in the AS path information.

   I suggest
"
" The AS4_PATH attribute, being Optional Transitive, must (per [RFC4271])
" be advertised unmodified by the OLD BGP speaker to any peer to which
" it advertises that NLRI. Thus, after passing through any number of OLD
" BGP speakers, the AS4_PATH will emerge unmodified to the first NEW
" speaker that encounters it.

] Similarly, if the NEW speaker has to send the AGGREGATOR attribute,
] and if the aggregating Autonomous System's AS number is a non-
] mappable 4-octet AS number, then the speaker MUST use the
] AS4_AGGREGATOR attribute, and set the AS number field in the existing
] AGGREGATOR attribute to the reserved AS number, AS_TRANS.  Note that
] if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute
] MUST NOT be sent.

   I suggest
"
" If the NEW BGP speaker includes an AGGREGATOR attribute in an UPDATE
" to an OLD BGP speaker, it MUST check whether the aggregating AS
" number is a 32-bit AS number, and if it is it MUST also include an
" AS4_AGGREGATOR attribute with a 4-octet AS number (in addition to
" the 2-octet AS_TRANS in the AGGREGATOR attribute.

] 4.2.3. Processing Received Updates
]
] When a NEW BGP speaker receives an update from an OLD one, it should
                                                                ^^^^^^
   Replace with MUST

] be prepared to receive the AS4_PATH attribute along with the existing
] AS_PATH attribute.  If the AS4_PATH attribute is also received,
                                                                ^
   Add "and passes certain validity checks"

] both the attributes will be used to construct the exact AS path
] information, and therefore the information carried by both the
] attributes will be considered for AS path loop detection.

   I'd simplify
"
" the AS4_PATH attribute (and AS4_AGGREGATOR) will be used to supplement
" the AS_PATH attribute in constructing the (internal) AS path and in
" checking for AS path loops.

] Note that a route may have traversed a series of autonomous systems
] with 2-octet AS numbers and OLD BGP speakers only.  In that case, if
] the route carries the AS4_PATH attribute, this attribute must have
] remained unmodified since the route left the last NEW BGP speaker.

   I'd delete this. (I think we've covered it already.)

] The trailing AS path information (representing autonomous systems
] with 2-octet AS numbers and OLD BGP speakers only) is contained only
] in the current AS_PATH attribute (encoded in the leading part of the
] AS_PATH attribute).

   No change.

] Under certain conditions, it may not be possible to reconstruct the
] entire AS path information from the AS_PATH and the AS4_PATH
] attributes of a route.

   I'd make this its own paragraph.

] This occurs
 ^^^^ ^^^^^^
   Change to "For example,"

] when two or more routes that carry the AS4_PATH attribute are
] aggregated by an OLD BGP speaker, and the AS4_PATH attribute of
] at least one of these routes carries at least one 4-octet AS number
] (as oppose to a 2-octet AS number that is encoded in 4 octets).

   Change to
" If an OLD BGP speaker aggregates routes, one or more of which contain
" the (unrecognized) AS4_PATH attribute, the 32-bit AS number(s) in
" that AS4_PATH attribute will generally be lost.

] Depending on the implementation, either the AS4_PATH attribute would
] be lost during route aggregation, or both the AS_PATH attribute and
] the AS4_PATH attribute would contain valid, partial information that
] cannot be combined seamlessly, resulting in incomplete AS path
] information in these cases.

   No change.

] A NEW BGP speaker should also be prepared to receive the
] AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an
] OLD BGP speaker. When both the attributes are received, if the AS
] number in the AGGREGATOR attribute is not AS_TRANS, then:
]
] -  the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL
]    be ignored,
] -  the AGGREGATOR attribute SHALL be taken as the information
]    about the aggregating node, and
] -  the AS_PATH attribute SHALL be taken as the AS path
]    information.
]
] Otherwise,

] -  the AGGREGATOR attribute SHALL be ignored,
] -  the AS4_AGGREGATOR attribute SHALL be taken as the information
]    about the aggregating node, and
] -  the AS path information would need to be constructed, as in all
]    other cases.

   No change needed, but I'd suggest swapping the order (putting "if
the AS number in the AGGREGATOR attribute is AS_TRANS" first).

] In order to construct the AS path information, it would be necessary
] to first calculate the number of AS numbers in the AS_PATH and
] AS4_PATH attributes using the method specified in Section 9.1.2.2
] [RFC4271] and [RFC5065] for route selection.
]
] If the number of AS numbers in the AS_PATH attribute is less than the
] number of AS numbers in the AS4_PATH attribute, then the AS4_PATH
] attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken
] as the AS path information.
]
] If the number of AS numbers in the AS_PATH attribute is larger than
] or equal to the number of AS numbers in the AS4_PATH attribute, then
] the AS path information SHALL be constructed by taking as many AS
] numbers and path segments as necessary from the leading part of the
] AS_PATH attribute, and then prepending them to the AS4_PATH attribute
] so that the AS path information has an identical number of AS numbers
] as the AS_PATH attribute.  Note that a valid AS_CONFED_SEQUENCE or
] AS_CONFED_SET path segment SHALL be prepended if it is either the
] leading path segment or adjacent to a path segment that is prepended.

   I don't feel able to clarify these paragraphs. Note, however, that
"Section 9.1.2.2 [RFC4271]" refers to "Breaking Ties" and may not be
the right reference.

   Also, I am not sure all implementations in the field blindly prepend
part of the AS_PATH to the AS4_PATH (though that clearly is what
RFC4893 calls for.

   Also, I frankly don't understand the last sentence about "Note that
a valid AS_CONFED_SEQUENCE...". It would be good, IMHO, to replace it
with clearer text about what happens to AS4_PATH in this case.

] 5. Handling BGP Communities

   No change. (But isn't RFC5668 a Normative reference?)

   Note, RFC5668 may not be implemented in all systems to which the
Extended Communities may be forwarded: I don't see a problem there, but
I may have missed one...

] 6. Error Handling
]
] The general guidelines presented in [OPT-TRANS]

   Another Normative reference...

] apply to the error
] handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in
] this document.  It is noted, however, that the nature (i.e., NEW
] speaker or OLD speaker) of a direct neighbor based on the
] announcement of the 4-octet AS Capability allows a local speaker to
] determine unequivocally whether the direct neighbor recognizes these
] new attributes.  Thus there is no need to examine the the attribute
] flags (somewhat weaker indicator in this case) for that
] determination.

   I think this is too vague: we should state clearly which flags are
to be checked. (I'm not sure what our consensus may be here.)

   Note also, that as a Normative reference, 4893bis would have to wait
for completion of draft-ietf-idr-optional-transitive before being
published.

   (BTW, the [OPT-TRANS] reference should clearly name the I-D title.)

] Given that the two-octet AS numbers dominate during the transition,
] and are carried in the AS_PATH attribute by an OLD BGP speaker, in
] this document the "attribute discard" approach is chosen to handle a
] malformed AS4_PATH attribute.

   I think we could safely prescribe that without needing a Normative
reference...

] Similarly, as the AS4_AGGREGATOR is just informational, the
] "attribute discard" approach is chosen to handle a malformed
] AS4_AGGREGATOR attribute.

   Likewise.

] The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be
] carried in an UPDATE message between NEW BGP speakers.  A NEW BGP
] speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR
] attribute in an UPDATE message from another NEW BGP speaker MUST
] discard the path attribute and continue processing the UPDATE
] message.  This case SHOULD be logged locally for analysis.

   No change.

] In addition, the path segment types AS_CONFED_SEQUENCE and
] AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute
] of an UPDATE message.  A NEW BGP speaker that receives these path
] segment types in the AS4_PATH attribute of an UPDATE message from an
] OLD BGP speaker MUST discard these path segments,

   No change.

] adjust the relevant attribute fields accordingly,

   IMHO, this is too vague (but I don't have text to propose).

] and continue processing the UPDATE message. This case SHOULD be logged
] locally for analysis.

   No change.

] The AS4_PATH attribute in an UPDATE message SHALL be considered
] malformed under the following conditions:
]
] - the attribute length is not a multiple of two, or is too small
]   (i.e., less than 6) for the attribute to carry at least one
]   AS number, or
]
] - the path segment length in the attribute is either zero, or
]   is inconsistent with the attribute length, or

   No change.

] - the path segment type in the attribute is not one of the
]   types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE
]   and AS_CONFED_SET.

   No specific change, but I'm not clear on this: it seems to complicate
the introduction of new path segments (for all I know, there may already
be some in the wild). We have no language in 4893bis to require stripping
these when creating an AS4_PATH.

] A NEW BGP speaker that receives a malformed AS4_PATH attribute in an
] UPDATE message from an OLD BGP speaker MUST discard the attribute,
] and continue processing the UPDATE message.  The error SHOULD be
] logged locally for analysis.
]
] The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered
] malformed if the attribute length is not 8.
]
] A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute
] in an UPDATE message from an OLD BGP speaker MUST discard the
] attribute, and continue processing the UPDATE message.  The error
] SHOULD be logged locally for analysis.

   No change.

] 7. Transition

   I think this section could be shortened.

] The scheme described in this document allows a gradual transition
] from 2-octet AS numbers to 4-octet AS numbers.  One can upgrade one
] Autonomous System or one BGP speaker at a time.

   Is this needed?

] To simplify transition, this document assumes that an Autonomous
] System could start using a 4-octet AS number only after all the BGP
] speakers within that Autonomous System have been upgraded to support
] 4-octet AS numbers.

   Is this needed? What happens if the condition isn't met?

] An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System
] number.

   Is this needed? We have no way to enforce it.

] A non-mappable 4-octet AS number cannot be used as a "Member AS
] Number" of a BGP Confederation until all the BGP speakers within the
] Confederation have transitioned to support 4-octet AS numbers.
                                             ^^^^^^^
   Change to "32-bit"

] In an environment where an Autonomous System that has OLD BGP
] speakers peers with two or more Autonomous Systems that have NEW BGP
] speakers and use AS_TRANS (rather than having a globally unique AS
] number), use of Multi-Exit Discriminators by the Autonomous System
] with the OLD speakers may result in a situation where Multi-Exit
] Discriminator will influence route selection among the routes that
] were received from different neighboring Autonomous Systems.

   I think this says the OLD BGP speaker cannot distinguish MEDs. We
have no way to enforce any behavior on OLD speakers, so if we say
anything here, it must be about what NEW speakers would do. I don't
know what to suggest. (Is this needed?)

] Under certain conditions, it may not be possible to reconstruct the
] entire AS path information from the AS_PATH and the AS4_PATH
] attributes of a route.  This occurs when two or more routes that
] carry the AS4_PATH attribute are aggregated by an OLD BGP speaker,
] and the AS4_PATH attribute of at least one of these routes carries at
] least one 4-octet AS number (as oppose to a 2-octet AS number that is
] encoded in 4 octets).
] When such aggregation results in creating a
] route that is less specific than any of the component routes (route
] whose Network Layer Reachability Information (NLRI) covers NLRI of
] all the component routes), loss of the AS path information does not
] create a risk of a routing loop.  In all other cases, loss of the AS
] path information does create a risk of a routing loop.

   Duplicate text, not needed here.

] When such aggregation results in creating a
] route that is less specific than any of the component routes (route
] whose Network Layer Reachability Information (NLRI) covers NLRI of
] all the component routes), loss of the AS path information does not
] create a risk of a routing loop.  In all other cases, loss of the AS
] path information does create a risk of a routing loop.

   If we're going to say anything about routing loops, I believe we
need to define "routing loop" and "forwarding loop"; and I'd strongly
recommend putting this in a different section.

8. IANA Considerations

] This document expands the pool for AS numbers from 0 - 65535 to 0 -
] 4294967295.  The AS numbers are managed by the IANA "Autonomous
] System Numbers" registry.  Other than expanding the AS number pool,
] this document does not propose any modifications to the existing
] policies and procedures pertaining to the AS number allocation.

   Delete. (already done, no IANA action needed)

] This document uses a BGP Capability code to indicate that a BGP
] speaker supports the 4-octet AS numbers.  The Capability Code 65 has
] been assigned by IANA per [RFC5492].

   No change.

] In addition, this document introduces two new BGP optional transitive
] attributes, and their type codes have been assigned by the IANA.  The
] first one is the AS4_PATH attribute, value 17, which preserves the AS
] path information with 4-octet AS numbers across old BGP speakers.
] The second one is the AS4_AGGREGATOR attribute, value 18, which is
] similar in use to the current AGGREGATOR attribute, but it carries a
] 4-octet AS number.

   Delete. (already done, no IANA action needed)

] Finally, this document introduces a reserved 2-octet AS number --
                         ^^^^^^^^^^
   Change to "describes the use of"

] AS_TRANS.  The AS number 23456 has been assigned by the IANA for
] AS_TRANS.

   Add: "IANA will need to update the 16-bit AS number registry to
point to this document.

] 9. Security Considerations

   A separate issue, not covered in this email...

--
John Leslie <john@jlc.net>
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--------------010806050506040507080202-- --------------040004070001000606070709 Content-Type: text/plain; name="draft-ietf-idr-rfc4893bis-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-idr-rfc4893bis-04.txt" Network Working Group Q. Vohra Internet Draft Juniper Networks Obsoletes: 4893 (if approved) E. Chen Intended Status: Standards Track Cisco Systems Expiration Date: Dec 28, 2011 June 27, 2011 BGP Support for Four-octet AS Number Space draft-ietf-idr-rfc4893bis-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 28, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. draft-ietf-idr-rfc4893bis-04.txt [Page 1] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 Abstract The Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. 1. Introduction In the base BGP specification [RFC4271] the Autonomous System number is encoded as a two-octet entity. To prepare for the anticipated exhaustion of the two-octet AS numbers, this document describes extensions to BGP to carry the Autonomous System numbers as four- octet entities. More specifically, this document defines a BGP capability, "support for 4-octet AS number capability", to be used by a BGP speaker to indicate its support for the four-octet AS numbers. Two attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to propagate four-octet based AS path information across BGP speakers that do not support the four-octet AS numbers. This document also specifies mechanisms for constructing the AS path information from the AS_PATH attribute and the AS4_PATH attribute. The extensions specified in this document allow a gradual transition from 2-octet AS numbers to 4-octet AS numbers. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Protocol Extensions For the purpose of this document we define a BGP speaker that does not support the new 4-octet AS number extensions as an OLD BGP speaker, and a BGP speaker that supports the new 4-octet AS number extensions as a NEW BGP speaker. BGP carries the Autonomous System numbers in the "My Autonomous System" field of the OPEN message, in the AS_PATH attribute of the UPDATE message, and in the AGGREGATOR attribute of the UPDATE message. BGP also carries the Autonomous System numbers in the BGP Communities attribute. draft-ietf-idr-rfc4893bis-04.txt [Page 2] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 A NEW BGP speaker uses BGP Capability Advertisements [RFC5492] to advertise to its neighbors (either internal or external) that it supports 4-octet AS number extensions, as specified in this document. The Capability that is used by a BGP speaker to convey to its BGP peer the 4-octet Autonomous System number capability, also carries the Autonomous System number (encoded as a 4-octet entity) of the speaker in the Capability Value field of the Capability Optional Parameter. The Capability Length field of the Capability is set to 4. The AS path information exchanged between NEW BGP speakers are carried in the existing AS_PATH attribute, except that each AS number in the attribute is encoded as a 4-octet entity (instead of a 2-octet entity). The same applies to the AGGREGATOR attribute - the same attribute is used between NEW BGP speakers, except that the AS number carried in the attribute is encoded as a 4-octet entity. The AS_PATH attribute and the AGGREGATOR attribute carried between a NEW BGP speaker and an OLD BGP speaker will continue to contain 2- octet AS numbers as specified in [RFC4271]. To preserve the AS path information with 4-octet AS numbers across OLD BGP speakers, this document defines a new AS path attribute, called AS4_PATH. This is an optional transitive attribute that contains the AS path encoded with 4-octet AS numbers. The AS4_PATH attribute has the same semantics as the AS_PATH attribute, except that it is optional transitive, and it carries 4-octet AS numbers. To prevent the possible propagation of confederation path segments outside of a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH attribute, and MUST NOT be included in the AS4_PATH attribute of an UPDATE message. Similarly, this document defines a new aggregator attribute called AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR attribute has the same semantics as the AGGREGATOR attribute, except that it carries a 4-octet AS number. Currently assigned 2-octet Autonomous System numbers are converted into 4-octet Autonomous System numbers by setting the two high-order octets of the 4-octet field to zero. Such a 4-octet AS number is said to be mappable to a 2-octet AS number. To represent 4-octet AS numbers (which are not mapped from 2-octets) as 2-octet AS numbers in the AS path information encoded with 2-octet AS numbers, this document reserves a 2-octet AS number. We denote draft-ietf-idr-rfc4893bis-04.txt [Page 3] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 this special AS number as AS_TRANS for ease of description in the rest of this specification. This AS number is also placed in the "My Autonomous System" field of the OPEN message originated by a NEW BGP speaker, if the speaker does not have a (globally unique) 2-octet AS number. 4. Operations 4.1. Interaction Between NEW BGP Speakers A BGP speaker that supports 4-octet Autonomous System numbers SHALL advertise this to its peers using the BGP Capability Advertisements. The Autonomous System number of the BGP speaker MUST be carried in the capability value field of the "support for 4-octet AS number capability". When a NEW BGP speaker processes an OPEN message from another NEW BGP speaker, it MUST use the Autonomous System number encoded in the Capability Value field of the Capability in lieu of the "My Autonomous System" field of the OPEN message. A BGP speaker that advertises such capability to a particular peer, and receives from that peer the advertisement of such capability MUST encode Autonomous System numbers as 4-octet entities in both the AS_PATH and the AGGREGATOR attributes in the updates it sends to the peer, and MUST assume that these attributes in the updates received from the peer encode Autonomous System numbers as 4-octet entities. The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried in an UPDATE message between NEW BGP speakers. A NEW BGP speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute in an UPDATE message from another NEW BGP speaker MUST discard the path attribute and continue processing the UPDATE message. 4.2. Interaction Between NEW and OLD BGP Speakers 4.2.1. BGP Peering Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it). draft-ietf-idr-rfc4893bis-04.txt [Page 4] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 4.2.2. Generating Updates When communicating with an OLD BGP speaker, a NEW speaker MUST send the AS path information in the AS_PATH attribute encoded with 2-octet AS numbers. The NEW speaker MUST also send the AS path information in the AS4_PATH attribute (encoded with 4-octet AS numbers), except for the case where the entire AS path information is composed of 2- octet AS numbers only. In this case, the NEW speaker MUST NOT send the AS4_PATH attribute. In the AS_PATH attribute encoded with 2-octet AS numbers, non- mappable 4-octet AS numbers are represented by the well-known 2-octet AS number, AS_TRANS. This will preserve the path length property of the AS path information and also help in updating the AS path information received on a NEW BGP speaker from an OLD speaker, as explained in the next section. The NEW speaker constructs the AS4_PATH attribute from the AS path information. Whenever the AS path information contains the AS_CONFED_SEQUENCE or AS_CONFED_SET path segment, the NEW BGP speaker MUST exclude such path segments from the AS4_PATH attribute being constructed. The AS4_PATH attribute, being optional transitive, will be carried across a series of OLD BGP speakers without modification and will help preserve the non-mappable 4-octet AS numbers in the AS path information. Similarly, if the NEW speaker has to send the AGGREGATOR attribute, and if the aggregating Autonomous System's AS number is a non- mappable 4-octet AS number, then the speaker MUST use the AS4_AGGREGATOR attribute, and set the AS number field in the existing AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute MUST NOT be sent. 4.2.3. Processing Received Updates When a NEW BGP speaker receives an update from an OLD one, it MUST be prepared to receive the AS4_PATH attribute along with the existing AS_PATH attribute. If the AS4_PATH attribute is also received, both the attributes will be used to construct the exact AS path information, and therefore the information carried by both the attributes will be considered for AS path loop detection. Note that a route may have traversed a series of autonomous systems with 2-octet AS numbers and OLD BGP speakers only. In that case, if draft-ietf-idr-rfc4893bis-04.txt [Page 5] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 the route carries the AS4_PATH attribute, this attribute must have remained unmodified since the route left the last NEW BGP speaker. The trailing AS path information (representing autonomous systems with 2-octet AS numbers and OLD BGP speakers only) is contained only in the current AS_PATH attribute (encoded in the leading part of the AS_PATH attribute). Under certain conditions, it may not be possible to reconstruct the entire AS path information from the AS_PATH and the AS4_PATH attributes of a route. This occurs, for example, when two or more routes that carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, and the AS4_PATH attribute of at least one of these routes carries at least one 4-octet AS number (as oppose to a 2-octet AS number that is encoded in 4 octets). Depending on the implementation, either the AS4_PATH attribute would be lost during route aggregation, or both the AS_PATH attribute and the AS4_PATH attribute would contain valid, partial information that cannot be combined seamlessly, resulting in incomplete AS path information in these cases. A NEW BGP speaker MUST also be prepared to receive the AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an OLD BGP speaker. When both the attributes are received, if the AS number in the AGGREGATOR attribute is not AS_TRANS, then: - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL be ignored, - the AGGREGATOR attribute SHALL be taken as the information about the aggregating node, and - the AS_PATH attribute SHALL be taken as the AS path information. Otherwise, - the AGGREGATOR attribute SHALL be ignored, - the AS4_AGGREGATOR attribute SHALL be taken as the information about the aggregating node, and - the AS path information would need to be constructed, as in all other cases. In order to construct the AS path information, it would be necessary to first calculate the number of AS numbers in the AS_PATH and AS4_PATH attributes using the method specified in Section 9.1.2.2 draft-ietf-idr-rfc4893bis-04.txt [Page 6] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 [RFC4271] and [RFC5065] for route selection. If the number of AS numbers in the AS_PATH attribute is less than the number of AS numbers in the AS4_PATH attribute, then the AS4_PATH attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken as the AS path information. If the number of AS numbers in the AS_PATH attribute is larger than or equal to the number of AS numbers in the AS4_PATH attribute, then the AS path information SHALL be constructed by taking as many AS numbers and path segments as necessary from the leading part of the AS_PATH attribute, and then prepending them to the AS4_PATH attribute so that the AS path information has an identical number of AS numbers as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or AS_CONFED_SET path segment SHALL be prepended if it is either the leading path segment or adjacent to a path segment that is prepended. 5. Handling BGP Communities As specified in [RFC1997], when the high-order two-octets of the community attribute is neither 0x0000 nor 0xffff, these two octets encode the Autonomous System number. Quite clearly this would not work for a NEW BGP speaker with a non-mappable 4-octet AS number. Such BGP speakers should use the Four-octet AS Specific Extended Communities [RFC5668] instead. 6. Error Handling It is noted that the nature (i.e., NEW speaker or OLD speaker) of a direct neighbor based on the announcement of the "support for 4-octet AS number capability" allows a local speaker to determine unequivocally whether the direct neighbor recognizes the AS4_PATH and AS4_AGGREGATOR attributes. Also, given that the two-octet AS numbers dominate during the transition, and are carried in the AS_PATH attribute by an OLD BGP speaker, in this document the "attribute discard" approach is chosen to handle a malformed AS4_PATH attribute. Similarly, as the AS4_AGGREGATOR is just informational, the "attribute discard" approach is chosen to handle a malformed AS4_AGGREGATOR attribute. The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be carried in an UPDATE message between NEW BGP speakers. A NEW BGP speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR draft-ietf-idr-rfc4893bis-04.txt [Page 7] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 attribute in an UPDATE message from another NEW BGP speaker MUST discard the path attribute and continue processing the UPDATE message. This case SHOULD be logged locally for analysis. In addition, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute of an UPDATE message. A NEW BGP speaker that receives these path segment types in the AS4_PATH attribute of an UPDATE message from an OLD BGP speaker MUST discard these path segments, adjust the relevant attribute fields accordingly, and continue processing the UPDATE message. This case SHOULD be logged locally for analysis. The AS4_PATH attribute in an UPDATE message SHALL be considered malformed under the following conditions: - the attribute length is not a multiple of two, or is too small (i.e., less than 6) for the attribute to carry at least one AS number, or - the path segment length in the attribute is either zero, or is inconsistent with the attribute length, or - the path segment type in the attribute is not one of the types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE and AS_CONFED_SET. A NEW BGP speaker that receives a malformed AS4_PATH attribute in an UPDATE message from an OLD BGP speaker MUST discard the attribute, and continue processing the UPDATE message. The error SHOULD be logged locally for analysis. The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered malformed if the attribute length is not 8. A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute in an UPDATE message from an OLD BGP speaker MUST discard the attribute, and continue processing the UPDATE message. The error SHOULD be logged locally for analysis. draft-ietf-idr-rfc4893bis-04.txt [Page 8] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 7. Transition The scheme described in this document allows a gradual transition from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one Autonomous System or one BGP speaker at a time. To simplify transition, this document assumes that an Autonomous System could start using a 4-octet AS number only after all the BGP speakers within that Autonomous System have been upgraded to support 4-octet AS numbers. A non-mappable 4-octet AS number cannot be used as a "Member AS Number" of a BGP Confederation until all the BGP speakers within the Confederation have transitioned to support 4-octet AS numbers. In an environment where an Autonomous System that has OLD BGP speakers peers with two or more Autonomous Systems that have NEW BGP speakers and use AS_TRANS (rather than having a globally unique AS number), use of Multi-Exit Discriminators by the Autonomous System with the OLD speakers may result in a situation where Multi-Exit Discriminator will influence route selection among the routes that were received from different neighboring Autonomous Systems. Under certain conditions, it may not be possible to reconstruct the entire AS path information from the AS_PATH and the AS4_PATH attributes of a route. This occurs when two or more routes that carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, and the AS4_PATH attribute of at least one of these routes carries at least one 4-octet AS number (as oppose to a 2-octet AS number that is encoded in 4 octets). When such aggregation results in creating a route that is less specific than any of the component routes (route whose Network Layer Reachability Information (NLRI) covers NLRI of all the component routes), loss of the AS path information does not create a risk of a routing loop. In all other cases, loss of the AS path information does create a risk of a routing loop. draft-ietf-idr-rfc4893bis-04.txt [Page 9] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 8. IANA Considerations This document expands the pool for AS numbers from 0 - 65535 to 0 - 4294967295. The AS numbers are managed by the IANA "Autonomous System Numbers" registry. Other than expanding the AS number pool, this document does not propose any modifications to the existing policies and procedures pertaining to the AS number allocation. This document uses a BGP Capability code to indicate that a BGP speaker supports the 4-octet AS numbers. The Capability Code 65 has been assigned by IANA per [RFC5492]. In addition, this document introduces two BGP optional transitive attributes, and their type codes have been assigned by the IANA. The first one is the AS4_PATH attribute, value 17, which preserves the AS path information with 4-octet AS numbers across old BGP speakers. The second one is the AS4_AGGREGATOR attribute, value 18, which is similar in use to the current AGGREGATOR attribute, but it carries a 4-octet AS number. Finally, this document introduces a reserved 2-octet AS number -- AS_TRANS. The AS number 23456 has been assigned by the IANA for AS_TRANS. 9. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing BGP, except for the following: The inconsistency between the AS_PATH attribute and the AS4_PATH attribute can create loss of the AS path information, and potential routing loops in certain cases as discussed in the document. This could be exploited by an attacker. It is a misconfiguration to assign a non-mappable 4-octet AS number as the "Member AS Number" in a BGP confederation before all the BGP speakers within the confederation have transitioned to support 4- octet AS numbers. Such a misconfiguration would weaken the AS path loop detection within a confederation. draft-ietf-idr-rfc4893bis-04.txt [Page 10] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 10. Acknowledgments The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, and Jeffrey Haas for the numerous discussions that went into the making of this document. The authors would also like to thank members of the IDR Working Group for their review and comments. 11. References 11.1. Normative References [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009. [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5668] Rekhter, Y., Ramachandra, S., and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, October 2009. Appendix A. Comparison with RFC 4893 This document includes several editorial changes, and specifies the error handling for the new attributes. draft-ietf-idr-rfc4893bis-04.txt [Page 11] Internet Draft draft-ietf-idr-rfc4893bis-04.txt June 20, 2011 12. Authors' Addresses Quaizar Vohra Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA EMail: quaizar.vohra@gmail.com Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA EMail: enkechen@cisco.com draft-ietf-idr-rfc4893bis-04.txt [Page 12] --------------040004070001000606070709-- From internet-drafts@ietf.org Tue Jun 28 01:34:38 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9C221F8697; Tue, 28 Jun 2011 01:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS5MmCZ3u82u; Tue, 28 Jun 2011 01:34:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB2E21F8692; Tue, 28 Jun 2011 01:34:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110628083438.13101.62338.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 01:34:38 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 08:34:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Extended Message support for BGP Author(s) : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-01.txt Pages : 5 Date : 2011-06-28 The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension to BGP to extend its current message size from 4096 octets to 65535 octets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-extended-messages-01= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-extended-messages-01.= txt From enkechen@cisco.com Wed Jun 29 09:24:41 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFD79E8052 for ; Wed, 29 Jun 2011 09:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN8o8jo6lKtc for ; Wed, 29 Jun 2011 09:24:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 423FD9E800B for ; Wed, 29 Jun 2011 09:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5341; q=dns/txt; s=iport; t=1309364680; x=1310574280; h=message-id:date:from:mime-version:to:cc:subject; bh=E4uS9wzqW1KYrGcVkbUnpeoQwf8T5URQ8gBjx+sWUKA=; b=OTZGGQG+WP5AiM0yW6MJpfeOAZs393Mss3ybAbm0JSwtCWKuSYs9in8j Ycl1zUPOu5vUcJSukmE64zCQVgLgnlyv+Tubu6WuRiFjNnuSu7MGbibIH 7yo9RyWjo5g49DZ61h6L3/874Ten+swUDYkd6rbEQClkDmXHCAVTDO0mO I=; X-IronPort-AV: E=Sophos;i="4.65,444,1304294400"; d="scan'208,217";a="388592296" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 29 Jun 2011 16:24:40 +0000 Received: from enkechen-mac.local ([10.21.118.233]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5TGOd7O016369; Wed, 29 Jun 2011 16:24:39 GMT Message-ID: <4E0B5213.90105@cisco.com> Date: Wed, 29 Jun 2011 09:25:55 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "idr@ietf.org" Content-Type: multipart/alternative; boundary="------------070501060605040202010108" Cc: Keyur Patel Subject: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:24:41 -0000 This is a multi-part message in MIME format. --------------070501060605040202010108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. Will appreciate your comments. Regards, -- Enke -------- Original Message -------- Subject: I-D Action: draft-keyur-idr-enhanced-gr-00.txt Date: Wed, 29 Jun 2011 09:21:21 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Accelerated Routing Convergence for BGP Graceful Restart Author(s) : Keyur Patel Enke Chen Rex Fernando John Scudder Filename : draft-keyur-idr-enhanced-gr-00.txt Pages : 9 Date : 2011-06-29 In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070501060605040202010108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.  Will appreciate your comments.

Regards,   -- Enke

-------- Original Message --------
Subject: I-D Action: draft-keyur-idr-enhanced-gr-00.txt
Date: Wed, 29 Jun 2011 09:21:21 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Accelerated Routing Convergence for BGP Graceful Restart
	Author(s)       : Keyur Patel
                          Enke Chen
                          Rex Fernando
                          John Scudder
	Filename        : draft-keyur-idr-enhanced-gr-00.txt
	Pages           : 9
	Date            : 2011-06-29

   In this document we specify extensions to BGP graceful restart in
   order to avoid unnecessary transmission of the routing information
   preserved across a session restart, thus accelerating the routing
   convergence.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--------------070501060605040202010108-- From jgs@juniper.net Wed Jun 29 09:38:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCC421F85D6 for ; Wed, 29 Jun 2011 09:38:45 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FioKXZq0Fps for ; Wed, 29 Jun 2011 09:38:44 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id A575521F85EC for ; Wed, 29 Jun 2011 09:37:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTgtUueJ1Kvp5Mwj98Evjvsdoz9hFM0l4@postini.com; Wed, 29 Jun 2011 09:37:15 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 29 Jun 2011 09:34:59 -0700 From: John Scudder To: "idr@ietf.org List" Date: Wed, 29 Jun 2011 09:34:55 -0700 Thread-Topic: [Idr] Pending errata for RFC 4271 Thread-Index: Acw2enzNbdynIxPHRsedKtPGrkNuZA== Message-ID: References: <98AE7C11-49DD-4622-A623-3A3BC1626448@juniper.net> <00fb01cc2f57$007aa680$4001a8c0@gateway.2wire.net> <552BB225-AEC5-4812-8812-ABEAEAB5911D@tony.li> <31E9F278-0862-4559-AD38-26FAFD620E88@juniper.net> <017001cc2f67$01121140$4001a8c0@gateway.2wire.net> In-Reply-To: <017001cc2f67$01121140$4001a8c0@gateway.2wire.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 Subject: Re: [Idr] Pending errata for RFC 4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:38:45 -0000 Folks, I requested Stewart to make the following updates: 150: Verified, but Editorial 2838: Verified 1332: Rejected (see mail thread for discussion) 1633: Verified FYI. --John From bruno.decraene@orange-ftgroup.com Thu Jun 30 08:11:13 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3375511E8183 for ; Thu, 30 Jun 2011 08:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0eHRCG7XSNT for ; Thu, 30 Jun 2011 08:11:12 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3715511E8182 for ; Thu, 30 Jun 2011 08:11:12 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 94B018B8005; Thu, 30 Jun 2011 17:11:56 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8C50E8B8004; Thu, 30 Jun 2011 17:11:56 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 17:11:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jun 2011 17:11:10 +0200 Message-ID: In-Reply-To: <4E0B5213.90105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt Thread-Index: Acw2eRRJWAhmePI8S9uK7kMtK6DlbAAsJJrQ References: <4E0B5213.90105@cisco.com> From: To: X-OriginalArrivalTime: 30 Jun 2011 15:11:11.0445 (UTC) FILETIME=[F2483850:01CC3737] Cc: idr@ietf.org Subject: Re: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:11:13 -0000 Keyur, Enke, Rex, John, > FYI. Will appreciate your comments. Please find below some comments on your draft. 5. Operation 1) "Once the acknowledgment from a peer is not received within the specified upper bound, and the maintained state is compromised, then the speaker MUST clear the "TX Routing State" in the GR Capability to be advertised to the peer in the next session restart." Is there a chance to be able to achieve a resync some time later within = the same BGP session? E.g. if latter on we receive an acknowledgement, = is it possible to start again sending a new version number & maintaining = the required state? If so IMHO it could useful to say so since current = sentence could be understood as prohibiting this ("MUST clear the "TX = Routing State" in the GR Capability to be advertised to the peer in the = next session restart.") 2) " During the lifetime of an established session, if needed, a BGP speaker MAY use the UPDATE-VERSION message to request updates from the last update version that was previously acknowledged as long as the speaker has received the Enhanced GR Capability from its peer. When a BGP speaker receives such a request, it SHALL try to send routing information from the last acknowledged update version that the speaker has recorded. If the speaker is unable to do so for some reason (e.g., "slow peer"), then it SHOULD perform a route refresh using mechanism defined in [EH-RR] if possible. Otherwise, the BGP speaker SHOULD reset the session." - I would propose to add the following example as reason for not being = able to send the routes "did not maintained required states") - By "reset the session" do you mean sending a NOTIFICATION or = initiating an OPEN with GR enabled? (I understand the former, why not = using/allowing the latter?) Thanks Regards, Bruno --------------- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Enke Chen Sent: Wednesday, June 29, 2011 6:26 PM To: idr@ietf.org Cc: Keyur Patel Subject: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt FYI.=A0 Will appreciate your comments. Regards,=A0=A0 -- Enke -------- Original Message --------=20 Subject:=20 I-D Action: draft-keyur-idr-enhanced-gr-00.txt Date:=20 Wed, 29 Jun 2011 09:21:21 -0700 From:=20 internet-drafts@ietf.org Reply-To:=20 internet-drafts@ietf.org To:=20 i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Accelerated Routing Convergence for BGP Graceful = Restart Author(s) : Keyur Patel Enke Chen Rex Fernando John Scudder Filename : draft-keyur-idr-enhanced-gr-00.txt Pages : 9 Date : 2011-06-29 In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jgs@juniper.net Thu Jun 30 14:14:15 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0AC11E81F8 for ; Thu, 30 Jun 2011 14:14:15 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v+GKwF2E6ho for ; Thu, 30 Jun 2011 14:14:14 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7F71B11E81EE for ; Thu, 30 Jun 2011 14:14:13 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTgznI/NznrmBcoe2KMXIXnmbuH02qg8z@postini.com; Thu, 30 Jun 2011 14:14:14 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 30 Jun 2011 14:12:43 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 30 Jun 2011 14:12:42 -0700 Thread-Topic: [Idr] Adoption of "BGP Custom Decision" as WG Document Thread-Index: Acw3anO208YhxfvOT3mtbVgKuCvU+g== Message-ID: <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> References: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Russ White \(russwh\)" Subject: Re: [Idr] Adoption of "BGP Custom Decision" as WG Document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:14:15 -0000 Folks, There was reasonable support for this proposal at the IETF-80 meeting (http= ://www.ietf.org/proceedings/80/minutes/idr.txt), but there has been no foll= ow-up on the list. If you have any comments regarding WG adoption of the d= ocument, please send them by Friday, July 8. Thanks, --John On May 9, 2011, at 3:53 PM, Retana, Alvaro wrote: > Hi! > =20 > Following up on the meeting in Prague=85 > =20 > http://tools.ietf.org/html/draft-retana-bgp-custom-decision > =20 > We just published version -02. The only change from -01 is an update on = the authors=92 contact information. > =20 > As discussed during the meeting, this is the formal request for adoption = of this draft as a WG document. > =20 > The intended status is Standards Track. > =20 > Thoughts/comments? > =20 > Thanks! > =20 > Alvaro. From ilya@nobulus.com Thu Jun 30 14:20:13 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9D911E82B3 for ; Thu, 30 Jun 2011 14:20:13 -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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi9vE30SOOBo for ; Thu, 30 Jun 2011 14:20:12 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id A738E11E8283 for ; Thu, 30 Jun 2011 14:20:11 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 7A53217478; Thu, 30 Jun 2011 23:20:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id o8x4XX2ibhYU; Thu, 30 Jun 2011 23:19:30 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 8E92F17473; Thu, 30 Jun 2011 23:19:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ilya Varlashkin In-Reply-To: <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> Date: Thu, 30 Jun 2011 23:19:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net> <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" , "Russ White \(russwh\)" Subject: Re: [Idr] Adoption of "BGP Custom Decision" as WG Document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:20:13 -0000 I need to reread the doc once more before discussing possible = improvements but as I expressed in Prague in its current form document = can and should be adopted as WG document because it describes long = existing functionality. Whether this functionality needs further = tailoring or not we can sort out when it's WG item. So, support. Cheers, iLya On Jun 30, 2011, at 23:12 , John Scudder wrote: > Folks, >=20 > There was reasonable support for this proposal at the IETF-80 meeting = (http://www.ietf.org/proceedings/80/minutes/idr.txt), but there has been = no follow-up on the list. If you have any comments regarding WG = adoption of the document, please send them by Friday, July 8. >=20 > Thanks, >=20 > --John >=20 > On May 9, 2011, at 3:53 PM, Retana, Alvaro wrote: >=20 >> Hi! >>=20 >> Following up on the meeting in Prague=85 >>=20 >> http://tools.ietf.org/html/draft-retana-bgp-custom-decision >>=20 >> We just published version -02. The only change from -01 is an update = on the authors=92 contact information. >>=20 >> As discussed during the meeting, this is the formal request for = adoption of this draft as a WG document. >>=20 >> The intended status is Standards Track. >>=20 >> Thoughts/comments? >>=20 >> Thanks! >>=20 >> Alvaro. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 /iLya From internet-drafts@ietf.org Thu Jun 30 14:24:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7511E82DF; Thu, 30 Jun 2011 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5opJ7f6W2la; Thu, 30 Jun 2011 14:24:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F39711E8283; Thu, 30 Jun 2011 14:24:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110630212436.22888.3226.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 14:24:36 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ext-opt-param-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:24:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Extended Optional Parameters Length for BGP OPEN Message Author(s) : Enke Chen John Scudder Filename : draft-ietf-idr-ext-opt-param-02.txt Pages : 5 Date : 2011-06-30 The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we extend the BGP OPEN length field in a backward- compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-ext-opt-param-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-ext-opt-param-02.txt From jgs@juniper.net Thu Jun 30 14:41:13 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B5911E8314 for ; Thu, 30 Jun 2011 14:41:13 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgcT-kXPQ7bi for ; Thu, 30 Jun 2011 14:41:11 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 247AC11E830D for ; Thu, 30 Jun 2011 14:41:10 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTgztdB/X4CeK4GBWDWJ72eJ5DvjO+xoP@postini.com; Thu, 30 Jun 2011 14:41:10 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 30 Jun 2011 14:39:23 -0700 From: John Scudder To: Enke Chen Date: Thu, 30 Jun 2011 14:39:20 -0700 Thread-Topic: [Idr] WGLC for draft-ietf-idr-rfc4893bis-03.txt,BGP Support for Four-octet AS Number Space Thread-Index: Acw3biyVoIgSRs1jT++wen2AN9u58w== Message-ID: <66F06B41-31DE-4921-84E8-0E54D70B464D@juniper.net> References: <20101018152745.GT82074@verdi> <4E091B54.4090008@cisco.com> In-Reply-To: <4E091B54.4090008@cisco.com> 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 Cc: "idr@ietf.org" , John Leslie , "quaizar.vohra@gmail.com" Subject: Re: [Idr] WGLC for draft-ietf-idr-rfc4893bis-03.txt, BGP Support for Four-octet AS Number Space X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:41:13 -0000 Enke, In looking at your revisions and comparing to the suggestions from John Les= lie, the principal omission seems to be the careful distinction John drew b= etween "four-octet" and "32-bit" AS Numbers. To quote from John's review, = the distinction he draws is: " 32-bit AS number " An Autonomous System number in the range 65535-4294967295, as assigned " by IANA in the "32-bit Autonomous System Numbers" registry. ... " 4-octet AS number " The representation of AS numbers as defined in this document for NEW " BGP speakers, using 4 octets to hold a 32-bit unsigned number, with " high-order octets coming first. Basically this is a distinction between the number space and its representa= tion. I assume that in not adopting these changes, you are basically saying that = you feel the document is sufficiently clear as written. I would be interes= ted in hearing from the WG whether others feel the document would be signif= icantly clearer if John's proposed new definitions were adopted? In my opinion merely maintaining consistent language with 4893 isn't a main= goal as long as any terminology changes are done clearly and unambiguously= -- something the proposed introduction of a Definitions section would seem= to achieve. We shouldn't make changes just for fun, but if we do get impr= oved clarity then I think there is no impediment. Since this conversation has been moribund for some time and didn't involve = that many people even back in October, other opinions on this matter would = be welcome. (So would getting the document published and moving on. :-) Thanks, --John On Jun 27, 2011, at 8:07 PM, Enke Chen wrote: > Hi, John: > > Thanks a lot for your thorough review, and sorry for the long delay in ge= tting back. > > I have made quite a few editorial changes based on your suggestions. How= ever, there are also a few changes that do not seem necessary, and have bee= n left out. Given the maturity of the technology and the late stage of th= e document, I think that we should try to maintain the consistency with RFC= 4893, and limit the changes to the ones that are really required. > > Please take a look at the attached draft. If there are no major issues, = I will submit it in two weeks. > > -- Enke > > > On 10/18/10 8:27 AM, John Leslie wrote: >> John Scudder wrote: >> > >> > This is to start a working group last call on >> > draft-ietf-idr-rfc4893bis-03.txt, BGP Support for Four-octet >> > AS Number Space. Please send any comments to the list. >> > Please send your comments by Monday, October 18. >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-03.txt >> >> As threatened: ;^) >> >> ] Abstract >> ] >> ] Currently the Autonomous System (AS) number is encoded as a two-octet >> ] entity in BGP. >> >> Delete (outdated and unneeded) >> >> ] This document describes extensions to BGP to carry the >> ] Autonomous System number as a four-octet entity. >> >> (This is a sufficient Abstract.) >> >> ] 1. Introduction >> ] >> ] Currently the Autonomous System number is encoded as a two-octet >> ] entity in BGP [RFC4271]. >> >> Replace with >> " >> " In the base BGP specification [RFC4271] the Autonomous System number >> " is encoded as a two-octet entity. >> >> ] To prepare for the anticipated exhaustion of the two-octet AS numbers, >> >> Delete (outdated) and replace with >> " >> " With 32-bit AS numbers being allocated by registries, >> >> ] this document describes extensions to >> ] BGP to carry the Autonomous System number as a four-octet entity. >> ^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^^ >> Replace with plural: >> " >> " Autonomous System numbers >> >> ] More specifically, this document defines >> ] a new BGP capability, Four-octet AS Number Capability, >> ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Delete "new"; use IANA name "Support for 4-octet AS number capability= " >> >> ] that can be used by a BGP speaker to indicate its support... >> ^^^^ ^^^ ^^ ^^^^ >> Replace with "to be used" >> >> ] Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced... >> ^^^ >> Delete "new". >> >> ] 2. Specification of Requirements >> >> Rename as "Definitions"; add the following: >> " >> " 16-bit AS number >> " An Autonomous System number in the range 0-65535, as assigned by IANA >> " in the "16-bit Autonomous System Numbers" registry. >> " >> " 32-bit AS number >> " An Autonomous System number in the range 65535-4294967295, as assigned >> " by IANA in the "32-bit Autonomous System Numbers" registry. >> " >> " AS_TRANS >> " The 16-bit AS number assigned by IANA as a placeholder for 32-bit AS >> " numbers which don't fit in the base BGP spec. >> " >> " 2-octet AS number >> " The representation of AS numbers as defined in the BGP spec [RFC4271]. >> " >> " 4-octet AS number >> " The representation of AS numbers as defined in this document for NEW >> " BGP speakers, using 4 octets to hold a 32-bit unsigned number, with >> " high-order octets coming first. >> " >> " NEW BGP speaker >> " A BGP speaker that implements this specification and uses 4-octet >> " representation of AS numbers for sessions with other NEW BGP speakers. >> " >> " OLD BGP speaker >> " A BGP speaker that does not implement this specification, and MAY >> " carry 4-octet AS numbers (without being aware of them) in Optional >> " Transitive attributes defined in this specification. >> >> ] 3. Protocol Extensions >> ] >> ] For the purpose of this document we define a BGP speaker that does >> ] not support the new 4-octet AS number extensions as an OLD BGP >> ] speaker, and a BGP speaker that supports the new 4-octet AS number >> ] extensions as a NEW BGP speaker. >> >> Delete this paragraph (covered in Definitions). >> >> ] BGP carries the Autonomous System number in the... >> ^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^^ >> Change to plural (there isn't only one AS number). >> >> ] NEW BGP speakers carry AS path information expressed in terms of 4- >> ] octet Autonomous Systems numbers by using the existing AS_PATH >> ] attribute, except that each AS number in this attribute is encoded >> ] not as a 2-octet, but as a 4-octet entity. >> >> Reword to clarify: >> " >> " BGP sessions between NEW BGP speakers carry AS path information with >> " 4-octet AS numbers in the AS_PATH attribute (instead of 2-octet AS >> " numbers as specified in [RFC4271]). >> >> ] The same applies to the >> ] AGGREGATOR attribute - NEW BGP speakers use the same attribute, >> ] except that the AS carried in this attribute is encoded as a 4-octet >> ] entity. >> >> No change. >> >> Add before the next paragraph: >> " >> " For sessions between a NEW BGP speaker and an OLD BGP speaker, >> " AS_PATH and AGGREGATOR attributes will continue to contain 2-octet >> " AS numbers as specified in [RFC4271]. >> >> ] To preserve AS path information with 4-octet AS numbers across OLD... >> ^^^^^^^ >> Replace with "32-bit". >> >> ] The AS4_PATH attribute has >> ] the same semantics as the AS_PATH attribute, except that it is >> ] optional transitive, and it carries 4-octet AS numbers. >> ^ >> Add at end of sentence >> " >> " and certain components of an AS_PATH are prohibited >> >> ] To prevent the possible propagation of confederation path segments >> ] outside of a confederation, the path segment types AS_CONFED_SEQUENCE >> ] and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH >> ] attribute, and MUST NOT be carried in an UPDATE message. >> ^^^^ ^^^ ^^ ^^^^^^^ ^^ ^^ ^^^^^^ ^^^^^^^ >> Replace with >> " >> " MUST NOT be included in an AS4_PATH attribute sent in an UPDATE >> " message from a NEW BGP speaker to an OLD BGP speaker, even though >> " they are present in the AS_PATH attribute sent in that UPDATE. >> >> (I may have misunderstood this, but I can't read 4893-bis any other >> way.) >> >> ] Similarly, this document defines a new aggregator attribute called >> ] AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR >> ] attribute has the same semantics as the AGGREGATOR attribute, except >> ] that it carries a 4-octet AS number. >> >> No change. >> >> ] Currently assigned 2-octet Autonomous System numbers are converted >> ] into 4-octet Autonomous System numbers by setting the two high-order >> ] octets of the 4-octet field to zero. Such a 4-octet AS number is >> ] said to be mappable to a 2-octet AS number. >> >> Delete. (covered elsewhere; the "mappable" concept won't be needed) >> >> ] To represent 4-octet AS numbers (which are not mapped from 2-octets) >> ] as 2-octet AS numbers in the AS path information encoded with 2-octet >> ] AS numbers, this document reserves a 2-octet AS number. We denote >> ] this special AS number as AS_TRANS for ease of description in the >> ] rest of this specification. >> >> Replace with >> " >> " To represent 32-bit AS numbers in a BGP session between a NEW BGP >> " speaker and an OLD BGP speaker, IANA has reserved the AS number >> " "AS_TRANS". It is used (as a 2-octet AS number) wherever a 32-bit AS >> " number would otherwise overflow the 2-octet AS number representation >> " in an AS_PATH or AGGREGATOR attribute in an UPDATE sent by a NEW BGP >> " speaker to an OLD BGP speaker. >> >> ] This AS number is also placed in the "My Autonomous System" field of >> ] the OPEN message originated by a NEW BGP speaker, if the speaker >> ] does not have a (globally unique) 2-octet AS number. >> ^^^^^^^ >> Replace with "16-bit" >> >> ] 4. Operations >> ] 4.1. Interaction Between NEW BGP Speakers >> ] >> ] A BGP speaker that supports 4-octet Autonomous System numbers SHOULD >> ^^^^^^ >> Replace with MUST. >> >> (IMHO, if it doesn't advertise it it MUST behave exactly as an OLD >> BGP speaker, so it doesn't fit our definition of NEW BGP speaker.) >> >> ] advertise this to its peers using the BGP Capability Advertisements. >> ] The Autonomous System number of the BGP speaker MUST be carried in >> ] the capability value field of the advertised capability. >> ^^^^^^^^^^ >> Replace with "Support for 4-octet AS number" (IANA's name for it) >> >> ] When a NEW BGP speaker processes an OPEN message from another NEW BGP >> ] speaker, it MUST use the Autonomous System number encoded in the >> ] Capability Value field of the Capability in lieu of the "My >> ] Autonomous System" field of the OPEN message. >> >> No change (though it wouldn't hurt to repeat the IANA capability name= ) >> >> ] A BGP speaker that advertises such capability to a particular peer, >> ] and receives from that peer the advertisement of such capability MUST >> >> Change to >> " >> " A NEW BGP speaker that receives the Support for 4-octet AS number >> " capability from a peer MUST >> >> ] encode Autonomous System numbers as 4-octet entities in both the >> ] AS_PATH and the AGGREGATOR attributes in the updates it sends to the >> ] peer, and MUST assume that these attributes in the updates received >> ] from the peer encode Autonomous System numbers as 4-octet entities. >> >> No change. >> >> ] The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried >> ] in an UPDATE message between NEW BGP speakers. A NEW BGP speaker >> ] that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute >> ] in an UPDATE message from another NEW BGP speaker MUST discard the >> ] path attribute and continue processing the UPDATE message. >> >> No change. >> >> ] 4.2. Interaction Between NEW and OLD BGP Speakers >> ] 4.2.1. BGP Peering >> ] >> ] Note that peering between a NEW BGP speaker and an OLD one is >> ] possible only if the NEW BGP speaker has a 2-octet AS number. >> ^^^ ^ ^^^^^^^ >> Change to "uses a 16-bit" >> >> ] However, this document does not assume that an Autonomous System with >> ] NEW speakers has to have a globally unique 2-octet AS number -- >> ] AS_TRANS could be used instead (even if a multiple Autonomous System >> ] would use it). >> >> Change to >> " >> " A NEW BGP speaker which hasn't been assigned a 16-bit AS number will >> " still send OPEN messages to peers which may be OLD BGP speakers, >> " using AS_TRANS as the AS number in the OPEN message. >> " >> " This might lead to confusion if the OLD BGP speaker peers with two or >> " more Autonomous Systems which have not been assigned 16-bit AS numbers= . >> " Since the OLD BGP speaker will necessarily be unaware of this issue, >> " a NEW BGP speaker MAY pre-emptively close a session to an OLD BGP >> " speaker if this confusion is seen to be a problem. This SHOULD NOT be >> " the default configuration, though. >> >> ] 4.2.2. Generating Updates >> ] >> ] When communicating with an OLD BGP speaker, a NEW speaker MUST send >> ] the AS path information in the AS_PATH attribute encoded with 2-octet >> ] AS numbers. The NEW speaker MUST also send the AS path information >> ] in the AS4_PATH attribute (encoded with 4-octet AS numbers), except >> ] for the case where the entire AS path information is composed of 2- >> ] octet AS numbers only. In this case, the NEW speaker MUST NOT send >> ] the AS4_PATH attribute. >> >> No change proposed, but I'm nervous whether this MUST NOT is >> _always_ observed in the field. I'd suggest language to the effect that >> an AS4_PATH containing no 32-bit AS numbers SHOULD be ignored (but that >> strays into changing-bits-on-the wire territory). >> >> ] In the AS_PATH attribute encoded with 2-octet AS numbers, >> ] non-mappable 4-octet AS numbers are represented by the well-known >> ^^^^^^^^^^^^ ^^^^^^^ >> Change to "32-bit" ("non-mappable" isn't needed) >> >> ] 2-octet AS number, AS_TRANS. >> ^^^^^^^ >> Replace with "16-bit" >> >> ] This will preserve the path length property of the AS path information >> ] and also help in updating the AS path information received on a NEW >> ] BGP speaker from an OLD speaker, as explained in the next section. >> >> I suggest deleting this. (It's no longer _entirely_ true.) >> >> ] The NEW speaker constructs the AS4_PATH attribute from the AS path >> ] information. >> >> I suggest >> " >> " A NEW BGP speaker sending UPDATEs to an OLD BGP speaker constructs an >> " AS4_PATH attribute using the same (internal) information used to >> " construct the (2-octet) AS_PATH attribute. >> >> ] In the case where the AS path information contains >> ] either AS_CONFED_SEQUENCE or AS_CONFED_SET path segments, the NEW >> ] speaker, when constructing the AS4_PATH attribute from the AS path >> ] information, MUST exclude such path segments. >> >> I suggest >> " >> " Wherever this information contains AS_CONFED_SEQUENCE or AS_CONFED_SET >> " path segments, the NEW BGP speaker MUST exclude them from the AS4_PATH= . >> >> (I'm not clear whether also excluding them from the AS_PATH is >> permitted.) >> >> ] The AS4_PATH attribute >> ] will be carried across a series of OLD BGP speakers without >> ] modification and will help preserve the non-mappable 4-octet AS >> ] numbers in the AS path information. >> >> I suggest >> " >> " The AS4_PATH attribute, being Optional Transitive, must (per [RFC4271]= ) >> " be advertised unmodified by the OLD BGP speaker to any peer to which >> " it advertises that NLRI. Thus, after passing through any number of OLD >> " BGP speakers, the AS4_PATH will emerge unmodified to the first NEW >> " speaker that encounters it. >> >> ] Similarly, if the NEW speaker has to send the AGGREGATOR attribute, >> ] and if the aggregating Autonomous System's AS number is a non- >> ] mappable 4-octet AS number, then the speaker MUST use the >> ] AS4_AGGREGATOR attribute, and set the AS number field in the existing >> ] AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that >> ] if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute >> ] MUST NOT be sent. >> >> I suggest >> " >> " If the NEW BGP speaker includes an AGGREGATOR attribute in an UPDATE >> " to an OLD BGP speaker, it MUST check whether the aggregating AS >> " number is a 32-bit AS number, and if it is it MUST also include an >> " AS4_AGGREGATOR attribute with a 4-octet AS number (in addition to >> " the 2-octet AS_TRANS in the AGGREGATOR attribute. >> >> ] 4.2.3. Processing Received Updates >> ] >> ] When a NEW BGP speaker receives an update from an OLD one, it should >> ^^^^^^ >> Replace with MUST >> >> ] be prepared to receive the AS4_PATH attribute along with the existing >> ] AS_PATH attribute. If the AS4_PATH attribute is also received, >> ^ >> Add "and passes certain validity checks" >> >> ] both the attributes will be used to construct the exact AS path >> ] information, and therefore the information carried by both the >> ] attributes will be considered for AS path loop detection. >> >> I'd simplify >> " >> " the AS4_PATH attribute (and AS4_AGGREGATOR) will be used to supplement >> " the AS_PATH attribute in constructing the (internal) AS path and in >> " checking for AS path loops. >> >> ] Note that a route may have traversed a series of autonomous systems >> ] with 2-octet AS numbers and OLD BGP speakers only. In that case, if >> ] the route carries the AS4_PATH attribute, this attribute must have >> ] remained unmodified since the route left the last NEW BGP speaker. >> >> I'd delete this. (I think we've covered it already.) >> >> ] The trailing AS path information (representing autonomous systems >> ] with 2-octet AS numbers and OLD BGP speakers only) is contained only >> ] in the current AS_PATH attribute (encoded in the leading part of the >> ] AS_PATH attribute). >> >> No change. >> >> ] Under certain conditions, it may not be possible to reconstruct the >> ] entire AS path information from the AS_PATH and the AS4_PATH >> ] attributes of a route. >> >> I'd make this its own paragraph. >> >> ] This occurs >> ^^^^ ^^^^^^ >> Change to "For example," >> >> ] when two or more routes that carry the AS4_PATH attribute are >> ] aggregated by an OLD BGP speaker, and the AS4_PATH attribute of >> ] at least one of these routes carries at least one 4-octet AS number >> ] (as oppose to a 2-octet AS number that is encoded in 4 octets). >> >> Change to >> " If an OLD BGP speaker aggregates routes, one or more of which contain >> " the (unrecognized) AS4_PATH attribute, the 32-bit AS number(s) in >> " that AS4_PATH attribute will generally be lost. >> >> ] Depending on the implementation, either the AS4_PATH attribute would >> ] be lost during route aggregation, or both the AS_PATH attribute and >> ] the AS4_PATH attribute would contain valid, partial information that >> ] cannot be combined seamlessly, resulting in incomplete AS path >> ] information in these cases. >> >> No change. >> >> ] A NEW BGP speaker should also be prepared to receive the >> ] AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an >> ] OLD BGP speaker. When both the attributes are received, if the AS >> ] number in the AGGREGATOR attribute is not AS_TRANS, then: >> ] >> ] - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL >> ] be ignored, >> ] - the AGGREGATOR attribute SHALL be taken as the information >> ] about the aggregating node, and >> ] - the AS_PATH attribute SHALL be taken as the AS path >> ] information. >> ] >> ] Otherwise, >> >> ] - the AGGREGATOR attribute SHALL be ignored, >> ] - the AS4_AGGREGATOR attribute SHALL be taken as the information >> ] about the aggregating node, and >> ] - the AS path information would need to be constructed, as in all >> ] other cases. >> >> No change needed, but I'd suggest swapping the order (putting "if >> the AS number in the AGGREGATOR attribute is AS_TRANS" first). >> >> ] In order to construct the AS path information, it would be necessary >> ] to first calculate the number of AS numbers in the AS_PATH and >> ] AS4_PATH attributes using the method specified in Section 9.1.2.2 >> ] [RFC4271] and [RFC5065] for route selection. >> ] >> ] If the number of AS numbers in the AS_PATH attribute is less than the >> ] number of AS numbers in the AS4_PATH attribute, then the AS4_PATH >> ] attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken >> ] as the AS path information. >> ] >> ] If the number of AS numbers in the AS_PATH attribute is larger than >> ] or equal to the number of AS numbers in the AS4_PATH attribute, then >> ] the AS path information SHALL be constructed by taking as many AS >> ] numbers and path segments as necessary from the leading part of the >> ] AS_PATH attribute, and then prepending them to the AS4_PATH attribute >> ] so that the AS path information has an identical number of AS numbers >> ] as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or >> ] AS_CONFED_SET path segment SHALL be prepended if it is either the >> ] leading path segment or adjacent to a path segment that is prepended. >> >> I don't feel able to clarify these paragraphs. Note, however, that >> "Section 9.1.2.2 [RFC4271]" refers to "Breaking Ties" and may not be >> the right reference. >> >> Also, I am not sure all implementations in the field blindly prepend >> part of the AS_PATH to the AS4_PATH (though that clearly is what >> RFC4893 calls for. >> >> Also, I frankly don't understand the last sentence about "Note that >> a valid AS_CONFED_SEQUENCE...". It would be good, IMHO, to replace it >> with clearer text about what happens to AS4_PATH in this case. >> >> ] 5. Handling BGP Communities >> >> No change. (But isn't RFC5668 a Normative reference?) >> >> Note, RFC5668 may not be implemented in all systems to which the >> Extended Communities may be forwarded: I don't see a problem there, but >> I may have missed one... >> >> ] 6. Error Handling >> ] >> ] The general guidelines presented in [OPT-TRANS] >> >> Another Normative reference... >> >> ] apply to the error >> ] handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in >> ] this document. It is noted, however, that the nature (i.e., NEW >> ] speaker or OLD speaker) of a direct neighbor based on the >> ] announcement of the 4-octet AS Capability allows a local speaker to >> ] determine unequivocally whether the direct neighbor recognizes these >> ] new attributes. Thus there is no need to examine the the attribute >> ] flags (somewhat weaker indicator in this case) for that >> ] determination. >> >> I think this is too vague: we should state clearly which flags are >> to be checked. (I'm not sure what our consensus may be here.) >> >> Note also, that as a Normative reference, 4893bis would have to wait >> for completion of draft-ietf-idr-optional-transitive before being >> published. >> >> (BTW, the [OPT-TRANS] reference should clearly name the I-D title.) >> >> ] Given that the two-octet AS numbers dominate during the transition, >> ] and are carried in the AS_PATH attribute by an OLD BGP speaker, in >> ] this document the "attribute discard" approach is chosen to handle a >> ] malformed AS4_PATH attribute. >> >> I think we could safely prescribe that without needing a Normative >> reference... >> >> ] Similarly, as the AS4_AGGREGATOR is just informational, the >> ] "attribute discard" approach is chosen to handle a malformed >> ] AS4_AGGREGATOR attribute. >> >> Likewise. >> >> ] The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be >> ] carried in an UPDATE message between NEW BGP speakers. A NEW BGP >> ] speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR >> ] attribute in an UPDATE message from another NEW BGP speaker MUST >> ] discard the path attribute and continue processing the UPDATE >> ] message. This case SHOULD be logged locally for analysis. >> >> No change. >> >> ] In addition, the path segment types AS_CONFED_SEQUENCE and >> ] AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute >> ] of an UPDATE message. A NEW BGP speaker that receives these path >> ] segment types in the AS4_PATH attribute of an UPDATE message from an >> ] OLD BGP speaker MUST discard these path segments, >> >> No change. >> >> ] adjust the relevant attribute fields accordingly, >> >> IMHO, this is too vague (but I don't have text to propose). >> >> ] and continue processing the UPDATE message. This case SHOULD be logged >> ] locally for analysis. >> >> No change. >> >> ] The AS4_PATH attribute in an UPDATE message SHALL be considered >> ] malformed under the following conditions: >> ] >> ] - the attribute length is not a multiple of two, or is too small >> ] (i.e., less than 6) for the attribute to carry at least one >> ] AS number, or >> ] >> ] - the path segment length in the attribute is either zero, or >> ] is inconsistent with the attribute length, or >> >> No change. >> >> ] - the path segment type in the attribute is not one of the >> ] types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE >> ] and AS_CONFED_SET. >> >> No specific change, but I'm not clear on this: it seems to complicate >> the introduction of new path segments (for all I know, there may already >> be some in the wild). We have no language in 4893bis to require strippin= g >> these when creating an AS4_PATH. >> >> ] A NEW BGP speaker that receives a malformed AS4_PATH attribute in an >> ] UPDATE message from an OLD BGP speaker MUST discard the attribute, >> ] and continue processing the UPDATE message. The error SHOULD be >> ] logged locally for analysis. >> ] >> ] The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered >> ] malformed if the attribute length is not 8. >> ] >> ] A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute >> ] in an UPDATE message from an OLD BGP speaker MUST discard the >> ] attribute, and continue processing the UPDATE message. The error >> ] SHOULD be logged locally for analysis. >> >> No change. >> >> ] 7. Transition >> >> I think this section could be shortened. >> >> ] The scheme described in this document allows a gradual transition >> ] from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one >> ] Autonomous System or one BGP speaker at a time. >> >> Is this needed? >> >> ] To simplify transition, this document assumes that an Autonomous >> ] System could start using a 4-octet AS number only after all the BGP >> ] speakers within that Autonomous System have been upgraded to support >> ] 4-octet AS numbers. >> >> Is this needed? What happens if the condition isn't met? >> >> ] An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System >> ] number. >> >> Is this needed? We have no way to enforce it. >> >> ] A non-mappable 4-octet AS number cannot be used as a "Member AS >> ] Number" of a BGP Confederation until all the BGP speakers within the >> ] Confederation have transitioned to support 4-octet AS numbers. >> ^^^^^^^ >> Change to "32-bit" >> >> ] In an environment where an Autonomous System that has OLD BGP >> ] speakers peers with two or more Autonomous Systems that have NEW BGP >> ] speakers and use AS_TRANS (rather than having a globally unique AS >> ] number), use of Multi-Exit Discriminators by the Autonomous System >> ] with the OLD speakers may result in a situation where Multi-Exit >> ] Discriminator will influence route selection among the routes that >> ] were received from different neighboring Autonomous Systems. >> >> I think this says the OLD BGP speaker cannot distinguish MEDs. We >> have no way to enforce any behavior on OLD speakers, so if we say >> anything here, it must be about what NEW speakers would do. I don't >> know what to suggest. (Is this needed?) >> >> ] Under certain conditions, it may not be possible to reconstruct the >> ] entire AS path information from the AS_PATH and the AS4_PATH >> ] attributes of a route. This occurs when two or more routes that >> ] carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, >> ] and the AS4_PATH attribute of at least one of these routes carries at >> ] least one 4-octet AS number (as oppose to a 2-octet AS number that is >> ] encoded in 4 octets). >> ] When such aggregation results in creating a >> ] route that is less specific than any of the component routes (route >> ] whose Network Layer Reachability Information (NLRI) covers NLRI of >> ] all the component routes), loss of the AS path information does not >> ] create a risk of a routing loop. In all other cases, loss of the AS >> ] path information does create a risk of a routing loop. >> >> Duplicate text, not needed here. >> >> ] When such aggregation results in creating a >> ] route that is less specific than any of the component routes (route >> ] whose Network Layer Reachability Information (NLRI) covers NLRI of >> ] all the component routes), loss of the AS path information does not >> ] create a risk of a routing loop. In all other cases, loss of the AS >> ] path information does create a risk of a routing loop. >> >> If we're going to say anything about routing loops, I believe we >> need to define "routing loop" and "forwarding loop"; and I'd strongly >> recommend putting this in a different section. >> >> 8. IANA Considerations >> >> ] This document expands the pool for AS numbers from 0 - 65535 to 0 - >> ] 4294967295. The AS numbers are managed by the IANA "Autonomous >> ] System Numbers" registry. Other than expanding the AS number pool, >> ] this document does not propose any modifications to the existing >> ] policies and procedures pertaining to the AS number allocation. >> >> Delete. (already done, no IANA action needed) >> >> ] This document uses a BGP Capability code to indicate that a BGP >> ] speaker supports the 4-octet AS numbers. The Capability Code 65 has >> ] been assigned by IANA per [RFC5492]. >> >> No change. >> >> ] In addition, this document introduces two new BGP optional transitive >> ] attributes, and their type codes have been assigned by the IANA. The >> ] first one is the AS4_PATH attribute, value 17, which preserves the AS >> ] path information with 4-octet AS numbers across old BGP speakers. >> ] The second one is the AS4_AGGREGATOR attribute, value 18, which is >> ] similar in use to the current AGGREGATOR attribute, but it carries a >> ] 4-octet AS number. >> >> Delete. (already done, no IANA action needed) >> >> ] Finally, this document introduces a reserved 2-octet AS number -- >> ^^^^^^^^^^ >> Change to "describes the use of" >> >> ] AS_TRANS. The AS number 23456 has been assigned by the IANA for >> ] AS_TRANS. >> >> Add: "IANA will need to update the 16-bit AS number registry to >> point to this document. >> >> ] 9. Security Considerations >> >> A separate issue, not covered in this email... >> >> -- >> John Leslie >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > From enkechen@cisco.com Thu Jun 30 14:51:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E5A11E80CB for ; Thu, 30 Jun 2011 14:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UTctFgGTQds for ; Thu, 30 Jun 2011 14:51:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 672D211E8075 for ; Thu, 30 Jun 2011 14:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=33315; q=dns/txt; s=iport; t=1309470693; x=1310680293; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k+r3S5hrd/+lOeuFmKuLzX6BdxQQFJ5dpRYDw1aOEYc=; b=ibSoA7TzgTrXuTosBLOK/m2QYeb72unCd9ekelK6SZodVF20wwvfVBUN Fq+JAmMklb/lkpq6A0dq34GDCq2cq2nlPHyAeyAoOOLw/MwIs93pXa9Qi +zhHxbe4vNzousnWDsvU1WWx0bj37gnUI/6vv4pZ/LmyXUyQyoGU16SuC c=; X-IronPort-AV: E=Sophos;i="4.65,454,1304294400"; d="scan'208";a="473077148" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2011 21:51:33 +0000 Received: from enkechen-mac.local ([10.155.35.248]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ULpVaG019552; Thu, 30 Jun 2011 21:51:32 GMT Message-ID: <4E0CF02F.30403@cisco.com> Date: Thu, 30 Jun 2011 14:52:47 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: John Scudder References: <20101018152745.GT82074@verdi> <4E091B54.4090008@cisco.com> <66F06B41-31DE-4921-84E8-0E54D70B464D@juniper.net> In-Reply-To: <66F06B41-31DE-4921-84E8-0E54D70B464D@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" , John Leslie , "quaizar.vohra@gmail.com" Subject: Re: [Idr] WGLC for draft-ietf-idr-rfc4893bis-03.txt, BGP Support for Four-octet AS Number Space X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:51:36 -0000 Hi, John: Yes, I feel that the document is sufficiently clear using the terms "mappable to 2-octet AS number" and "non-mappable" in the places where the distinctions need to be made. (Introducing the definitions as John L. suggested would result in a number of changes in the document, which I think, can be avoided.) Thanks. -- Enke On 6/30/11 2:39 PM, John Scudder wrote: > Enke, > > In looking at your revisions and comparing to the suggestions from John Leslie, the principal omission seems to be the careful distinction John drew between "four-octet" and "32-bit" AS Numbers. To quote from John's review, the distinction he draws is: > > " 32-bit AS number > " An Autonomous System number in the range 65535-4294967295, as assigned > " by IANA in the "32-bit Autonomous System Numbers" registry. > ... > " 4-octet AS number > " The representation of AS numbers as defined in this document for NEW > " BGP speakers, using 4 octets to hold a 32-bit unsigned number, with > " high-order octets coming first. > > Basically this is a distinction between the number space and its representation. > > I assume that in not adopting these changes, you are basically saying that you feel the document is sufficiently clear as written. I would be interested in hearing from the WG whether others feel the document would be significantly clearer if John's proposed new definitions were adopted? > > In my opinion merely maintaining consistent language with 4893 isn't a main goal as long as any terminology changes are done clearly and unambiguously -- something the proposed introduction of a Definitions section would seem to achieve. We shouldn't make changes just for fun, but if we do get improved clarity then I think there is no impediment. > > Since this conversation has been moribund for some time and didn't involve that many people even back in October, other opinions on this matter would be welcome. (So would getting the document published and moving on. :-) > > Thanks, > > --John > > On Jun 27, 2011, at 8:07 PM, Enke Chen wrote: > >> Hi, John: >> >> Thanks a lot for your thorough review, and sorry for the long delay in getting back. >> >> I have made quite a few editorial changes based on your suggestions. However, there are also a few changes that do not seem necessary, and have been left out. Given the maturity of the technology and the late stage of the document, I think that we should try to maintain the consistency with RFC 4893, and limit the changes to the ones that are really required. >> >> Please take a look at the attached draft. If there are no major issues, I will submit it in two weeks. >> >> -- Enke >> >> >> On 10/18/10 8:27 AM, John Leslie wrote: >>> John Scudder wrote: >>>> This is to start a working group last call on >>>> draft-ietf-idr-rfc4893bis-03.txt, BGP Support for Four-octet >>>> AS Number Space. Please send any comments to the list. >>>> Please send your comments by Monday, October 18. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-03.txt >>> As threatened: ;^) >>> >>> ] Abstract >>> ] >>> ] Currently the Autonomous System (AS) number is encoded as a two-octet >>> ] entity in BGP. >>> >>> Delete (outdated and unneeded) >>> >>> ] This document describes extensions to BGP to carry the >>> ] Autonomous System number as a four-octet entity. >>> >>> (This is a sufficient Abstract.) >>> >>> ] 1. Introduction >>> ] >>> ] Currently the Autonomous System number is encoded as a two-octet >>> ] entity in BGP [RFC4271]. >>> >>> Replace with >>> " >>> " In the base BGP specification [RFC4271] the Autonomous System number >>> " is encoded as a two-octet entity. >>> >>> ] To prepare for the anticipated exhaustion of the two-octet AS numbers, >>> >>> Delete (outdated) and replace with >>> " >>> " With 32-bit AS numbers being allocated by registries, >>> >>> ] this document describes extensions to >>> ] BGP to carry the Autonomous System number as a four-octet entity. >>> ^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^^ >>> Replace with plural: >>> " >>> " Autonomous System numbers >>> >>> ] More specifically, this document defines >>> ] a new BGP capability, Four-octet AS Number Capability, >>> ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> Delete "new"; use IANA name "Support for 4-octet AS number capability" >>> >>> ] that can be used by a BGP speaker to indicate its support... >>> ^^^^ ^^^ ^^ ^^^^ >>> Replace with "to be used" >>> >>> ] Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced... >>> ^^^ >>> Delete "new". >>> >>> ] 2. Specification of Requirements >>> >>> Rename as "Definitions"; add the following: >>> " >>> " 16-bit AS number >>> " An Autonomous System number in the range 0-65535, as assigned by IANA >>> " in the "16-bit Autonomous System Numbers" registry. >>> " >>> " 32-bit AS number >>> " An Autonomous System number in the range 65535-4294967295, as assigned >>> " by IANA in the "32-bit Autonomous System Numbers" registry. >>> " >>> " AS_TRANS >>> " The 16-bit AS number assigned by IANA as a placeholder for 32-bit AS >>> " numbers which don't fit in the base BGP spec. >>> " >>> " 2-octet AS number >>> " The representation of AS numbers as defined in the BGP spec [RFC4271]. >>> " >>> " 4-octet AS number >>> " The representation of AS numbers as defined in this document for NEW >>> " BGP speakers, using 4 octets to hold a 32-bit unsigned number, with >>> " high-order octets coming first. >>> " >>> " NEW BGP speaker >>> " A BGP speaker that implements this specification and uses 4-octet >>> " representation of AS numbers for sessions with other NEW BGP speakers. >>> " >>> " OLD BGP speaker >>> " A BGP speaker that does not implement this specification, and MAY >>> " carry 4-octet AS numbers (without being aware of them) in Optional >>> " Transitive attributes defined in this specification. >>> >>> ] 3. Protocol Extensions >>> ] >>> ] For the purpose of this document we define a BGP speaker that does >>> ] not support the new 4-octet AS number extensions as an OLD BGP >>> ] speaker, and a BGP speaker that supports the new 4-octet AS number >>> ] extensions as a NEW BGP speaker. >>> >>> Delete this paragraph (covered in Definitions). >>> >>> ] BGP carries the Autonomous System number in the... >>> ^^^ ^^^^^^^^^^ ^^^^^^ ^^^^^^ >>> Change to plural (there isn't only one AS number). >>> >>> ] NEW BGP speakers carry AS path information expressed in terms of 4- >>> ] octet Autonomous Systems numbers by using the existing AS_PATH >>> ] attribute, except that each AS number in this attribute is encoded >>> ] not as a 2-octet, but as a 4-octet entity. >>> >>> Reword to clarify: >>> " >>> " BGP sessions between NEW BGP speakers carry AS path information with >>> " 4-octet AS numbers in the AS_PATH attribute (instead of 2-octet AS >>> " numbers as specified in [RFC4271]). >>> >>> ] The same applies to the >>> ] AGGREGATOR attribute - NEW BGP speakers use the same attribute, >>> ] except that the AS carried in this attribute is encoded as a 4-octet >>> ] entity. >>> >>> No change. >>> >>> Add before the next paragraph: >>> " >>> " For sessions between a NEW BGP speaker and an OLD BGP speaker, >>> " AS_PATH and AGGREGATOR attributes will continue to contain 2-octet >>> " AS numbers as specified in [RFC4271]. >>> >>> ] To preserve AS path information with 4-octet AS numbers across OLD... >>> ^^^^^^^ >>> Replace with "32-bit". >>> >>> ] The AS4_PATH attribute has >>> ] the same semantics as the AS_PATH attribute, except that it is >>> ] optional transitive, and it carries 4-octet AS numbers. >>> ^ >>> Add at end of sentence >>> " >>> " and certain components of an AS_PATH are prohibited >>> >>> ] To prevent the possible propagation of confederation path segments >>> ] outside of a confederation, the path segment types AS_CONFED_SEQUENCE >>> ] and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH >>> ] attribute, and MUST NOT be carried in an UPDATE message. >>> ^^^^ ^^^ ^^ ^^^^^^^ ^^ ^^ ^^^^^^ ^^^^^^^ >>> Replace with >>> " >>> " MUST NOT be included in an AS4_PATH attribute sent in an UPDATE >>> " message from a NEW BGP speaker to an OLD BGP speaker, even though >>> " they are present in the AS_PATH attribute sent in that UPDATE. >>> >>> (I may have misunderstood this, but I can't read 4893-bis any other >>> way.) >>> >>> ] Similarly, this document defines a new aggregator attribute called >>> ] AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR >>> ] attribute has the same semantics as the AGGREGATOR attribute, except >>> ] that it carries a 4-octet AS number. >>> >>> No change. >>> >>> ] Currently assigned 2-octet Autonomous System numbers are converted >>> ] into 4-octet Autonomous System numbers by setting the two high-order >>> ] octets of the 4-octet field to zero. Such a 4-octet AS number is >>> ] said to be mappable to a 2-octet AS number. >>> >>> Delete. (covered elsewhere; the "mappable" concept won't be needed) >>> >>> ] To represent 4-octet AS numbers (which are not mapped from 2-octets) >>> ] as 2-octet AS numbers in the AS path information encoded with 2-octet >>> ] AS numbers, this document reserves a 2-octet AS number. We denote >>> ] this special AS number as AS_TRANS for ease of description in the >>> ] rest of this specification. >>> >>> Replace with >>> " >>> " To represent 32-bit AS numbers in a BGP session between a NEW BGP >>> " speaker and an OLD BGP speaker, IANA has reserved the AS number >>> " "AS_TRANS". It is used (as a 2-octet AS number) wherever a 32-bit AS >>> " number would otherwise overflow the 2-octet AS number representation >>> " in an AS_PATH or AGGREGATOR attribute in an UPDATE sent by a NEW BGP >>> " speaker to an OLD BGP speaker. >>> >>> ] This AS number is also placed in the "My Autonomous System" field of >>> ] the OPEN message originated by a NEW BGP speaker, if the speaker >>> ] does not have a (globally unique) 2-octet AS number. >>> ^^^^^^^ >>> Replace with "16-bit" >>> >>> ] 4. Operations >>> ] 4.1. Interaction Between NEW BGP Speakers >>> ] >>> ] A BGP speaker that supports 4-octet Autonomous System numbers SHOULD >>> ^^^^^^ >>> Replace with MUST. >>> >>> (IMHO, if it doesn't advertise it it MUST behave exactly as an OLD >>> BGP speaker, so it doesn't fit our definition of NEW BGP speaker.) >>> >>> ] advertise this to its peers using the BGP Capability Advertisements. >>> ] The Autonomous System number of the BGP speaker MUST be carried in >>> ] the capability value field of the advertised capability. >>> ^^^^^^^^^^ >>> Replace with "Support for 4-octet AS number" (IANA's name for it) >>> >>> ] When a NEW BGP speaker processes an OPEN message from another NEW BGP >>> ] speaker, it MUST use the Autonomous System number encoded in the >>> ] Capability Value field of the Capability in lieu of the "My >>> ] Autonomous System" field of the OPEN message. >>> >>> No change (though it wouldn't hurt to repeat the IANA capability name) >>> >>> ] A BGP speaker that advertises such capability to a particular peer, >>> ] and receives from that peer the advertisement of such capability MUST >>> >>> Change to >>> " >>> " A NEW BGP speaker that receives the Support for 4-octet AS number >>> " capability from a peer MUST >>> >>> ] encode Autonomous System numbers as 4-octet entities in both the >>> ] AS_PATH and the AGGREGATOR attributes in the updates it sends to the >>> ] peer, and MUST assume that these attributes in the updates received >>> ] from the peer encode Autonomous System numbers as 4-octet entities. >>> >>> No change. >>> >>> ] The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried >>> ] in an UPDATE message between NEW BGP speakers. A NEW BGP speaker >>> ] that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute >>> ] in an UPDATE message from another NEW BGP speaker MUST discard the >>> ] path attribute and continue processing the UPDATE message. >>> >>> No change. >>> >>> ] 4.2. Interaction Between NEW and OLD BGP Speakers >>> ] 4.2.1. BGP Peering >>> ] >>> ] Note that peering between a NEW BGP speaker and an OLD one is >>> ] possible only if the NEW BGP speaker has a 2-octet AS number. >>> ^^^ ^ ^^^^^^^ >>> Change to "uses a 16-bit" >>> >>> ] However, this document does not assume that an Autonomous System with >>> ] NEW speakers has to have a globally unique 2-octet AS number -- >>> ] AS_TRANS could be used instead (even if a multiple Autonomous System >>> ] would use it). >>> >>> Change to >>> " >>> " A NEW BGP speaker which hasn't been assigned a 16-bit AS number will >>> " still send OPEN messages to peers which may be OLD BGP speakers, >>> " using AS_TRANS as the AS number in the OPEN message. >>> " >>> " This might lead to confusion if the OLD BGP speaker peers with two or >>> " more Autonomous Systems which have not been assigned 16-bit AS numbers. >>> " Since the OLD BGP speaker will necessarily be unaware of this issue, >>> " a NEW BGP speaker MAY pre-emptively close a session to an OLD BGP >>> " speaker if this confusion is seen to be a problem. This SHOULD NOT be >>> " the default configuration, though. >>> >>> ] 4.2.2. Generating Updates >>> ] >>> ] When communicating with an OLD BGP speaker, a NEW speaker MUST send >>> ] the AS path information in the AS_PATH attribute encoded with 2-octet >>> ] AS numbers. The NEW speaker MUST also send the AS path information >>> ] in the AS4_PATH attribute (encoded with 4-octet AS numbers), except >>> ] for the case where the entire AS path information is composed of 2- >>> ] octet AS numbers only. In this case, the NEW speaker MUST NOT send >>> ] the AS4_PATH attribute. >>> >>> No change proposed, but I'm nervous whether this MUST NOT is >>> _always_ observed in the field. I'd suggest language to the effect that >>> an AS4_PATH containing no 32-bit AS numbers SHOULD be ignored (but that >>> strays into changing-bits-on-the wire territory). >>> >>> ] In the AS_PATH attribute encoded with 2-octet AS numbers, >>> ] non-mappable 4-octet AS numbers are represented by the well-known >>> ^^^^^^^^^^^^ ^^^^^^^ >>> Change to "32-bit" ("non-mappable" isn't needed) >>> >>> ] 2-octet AS number, AS_TRANS. >>> ^^^^^^^ >>> Replace with "16-bit" >>> >>> ] This will preserve the path length property of the AS path information >>> ] and also help in updating the AS path information received on a NEW >>> ] BGP speaker from an OLD speaker, as explained in the next section. >>> >>> I suggest deleting this. (It's no longer _entirely_ true.) >>> >>> ] The NEW speaker constructs the AS4_PATH attribute from the AS path >>> ] information. >>> >>> I suggest >>> " >>> " A NEW BGP speaker sending UPDATEs to an OLD BGP speaker constructs an >>> " AS4_PATH attribute using the same (internal) information used to >>> " construct the (2-octet) AS_PATH attribute. >>> >>> ] In the case where the AS path information contains >>> ] either AS_CONFED_SEQUENCE or AS_CONFED_SET path segments, the NEW >>> ] speaker, when constructing the AS4_PATH attribute from the AS path >>> ] information, MUST exclude such path segments. >>> >>> I suggest >>> " >>> " Wherever this information contains AS_CONFED_SEQUENCE or AS_CONFED_SET >>> " path segments, the NEW BGP speaker MUST exclude them from the AS4_PATH. >>> >>> (I'm not clear whether also excluding them from the AS_PATH is >>> permitted.) >>> >>> ] The AS4_PATH attribute >>> ] will be carried across a series of OLD BGP speakers without >>> ] modification and will help preserve the non-mappable 4-octet AS >>> ] numbers in the AS path information. >>> >>> I suggest >>> " >>> " The AS4_PATH attribute, being Optional Transitive, must (per [RFC4271]) >>> " be advertised unmodified by the OLD BGP speaker to any peer to which >>> " it advertises that NLRI. Thus, after passing through any number of OLD >>> " BGP speakers, the AS4_PATH will emerge unmodified to the first NEW >>> " speaker that encounters it. >>> >>> ] Similarly, if the NEW speaker has to send the AGGREGATOR attribute, >>> ] and if the aggregating Autonomous System's AS number is a non- >>> ] mappable 4-octet AS number, then the speaker MUST use the >>> ] AS4_AGGREGATOR attribute, and set the AS number field in the existing >>> ] AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that >>> ] if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute >>> ] MUST NOT be sent. >>> >>> I suggest >>> " >>> " If the NEW BGP speaker includes an AGGREGATOR attribute in an UPDATE >>> " to an OLD BGP speaker, it MUST check whether the aggregating AS >>> " number is a 32-bit AS number, and if it is it MUST also include an >>> " AS4_AGGREGATOR attribute with a 4-octet AS number (in addition to >>> " the 2-octet AS_TRANS in the AGGREGATOR attribute. >>> >>> ] 4.2.3. Processing Received Updates >>> ] >>> ] When a NEW BGP speaker receives an update from an OLD one, it should >>> ^^^^^^ >>> Replace with MUST >>> >>> ] be prepared to receive the AS4_PATH attribute along with the existing >>> ] AS_PATH attribute. If the AS4_PATH attribute is also received, >>> ^ >>> Add "and passes certain validity checks" >>> >>> ] both the attributes will be used to construct the exact AS path >>> ] information, and therefore the information carried by both the >>> ] attributes will be considered for AS path loop detection. >>> >>> I'd simplify >>> " >>> " the AS4_PATH attribute (and AS4_AGGREGATOR) will be used to supplement >>> " the AS_PATH attribute in constructing the (internal) AS path and in >>> " checking for AS path loops. >>> >>> ] Note that a route may have traversed a series of autonomous systems >>> ] with 2-octet AS numbers and OLD BGP speakers only. In that case, if >>> ] the route carries the AS4_PATH attribute, this attribute must have >>> ] remained unmodified since the route left the last NEW BGP speaker. >>> >>> I'd delete this. (I think we've covered it already.) >>> >>> ] The trailing AS path information (representing autonomous systems >>> ] with 2-octet AS numbers and OLD BGP speakers only) is contained only >>> ] in the current AS_PATH attribute (encoded in the leading part of the >>> ] AS_PATH attribute). >>> >>> No change. >>> >>> ] Under certain conditions, it may not be possible to reconstruct the >>> ] entire AS path information from the AS_PATH and the AS4_PATH >>> ] attributes of a route. >>> >>> I'd make this its own paragraph. >>> >>> ] This occurs >>> ^^^^ ^^^^^^ >>> Change to "For example," >>> >>> ] when two or more routes that carry the AS4_PATH attribute are >>> ] aggregated by an OLD BGP speaker, and the AS4_PATH attribute of >>> ] at least one of these routes carries at least one 4-octet AS number >>> ] (as oppose to a 2-octet AS number that is encoded in 4 octets). >>> >>> Change to >>> " If an OLD BGP speaker aggregates routes, one or more of which contain >>> " the (unrecognized) AS4_PATH attribute, the 32-bit AS number(s) in >>> " that AS4_PATH attribute will generally be lost. >>> >>> ] Depending on the implementation, either the AS4_PATH attribute would >>> ] be lost during route aggregation, or both the AS_PATH attribute and >>> ] the AS4_PATH attribute would contain valid, partial information that >>> ] cannot be combined seamlessly, resulting in incomplete AS path >>> ] information in these cases. >>> >>> No change. >>> >>> ] A NEW BGP speaker should also be prepared to receive the >>> ] AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an >>> ] OLD BGP speaker. When both the attributes are received, if the AS >>> ] number in the AGGREGATOR attribute is not AS_TRANS, then: >>> ] >>> ] - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL >>> ] be ignored, >>> ] - the AGGREGATOR attribute SHALL be taken as the information >>> ] about the aggregating node, and >>> ] - the AS_PATH attribute SHALL be taken as the AS path >>> ] information. >>> ] >>> ] Otherwise, >>> >>> ] - the AGGREGATOR attribute SHALL be ignored, >>> ] - the AS4_AGGREGATOR attribute SHALL be taken as the information >>> ] about the aggregating node, and >>> ] - the AS path information would need to be constructed, as in all >>> ] other cases. >>> >>> No change needed, but I'd suggest swapping the order (putting "if >>> the AS number in the AGGREGATOR attribute is AS_TRANS" first). >>> >>> ] In order to construct the AS path information, it would be necessary >>> ] to first calculate the number of AS numbers in the AS_PATH and >>> ] AS4_PATH attributes using the method specified in Section 9.1.2.2 >>> ] [RFC4271] and [RFC5065] for route selection. >>> ] >>> ] If the number of AS numbers in the AS_PATH attribute is less than the >>> ] number of AS numbers in the AS4_PATH attribute, then the AS4_PATH >>> ] attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken >>> ] as the AS path information. >>> ] >>> ] If the number of AS numbers in the AS_PATH attribute is larger than >>> ] or equal to the number of AS numbers in the AS4_PATH attribute, then >>> ] the AS path information SHALL be constructed by taking as many AS >>> ] numbers and path segments as necessary from the leading part of the >>> ] AS_PATH attribute, and then prepending them to the AS4_PATH attribute >>> ] so that the AS path information has an identical number of AS numbers >>> ] as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or >>> ] AS_CONFED_SET path segment SHALL be prepended if it is either the >>> ] leading path segment or adjacent to a path segment that is prepended. >>> >>> I don't feel able to clarify these paragraphs. Note, however, that >>> "Section 9.1.2.2 [RFC4271]" refers to "Breaking Ties" and may not be >>> the right reference. >>> >>> Also, I am not sure all implementations in the field blindly prepend >>> part of the AS_PATH to the AS4_PATH (though that clearly is what >>> RFC4893 calls for. >>> >>> Also, I frankly don't understand the last sentence about "Note that >>> a valid AS_CONFED_SEQUENCE...". It would be good, IMHO, to replace it >>> with clearer text about what happens to AS4_PATH in this case. >>> >>> ] 5. Handling BGP Communities >>> >>> No change. (But isn't RFC5668 a Normative reference?) >>> >>> Note, RFC5668 may not be implemented in all systems to which the >>> Extended Communities may be forwarded: I don't see a problem there, but >>> I may have missed one... >>> >>> ] 6. Error Handling >>> ] >>> ] The general guidelines presented in [OPT-TRANS] >>> >>> Another Normative reference... >>> >>> ] apply to the error >>> ] handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in >>> ] this document. It is noted, however, that the nature (i.e., NEW >>> ] speaker or OLD speaker) of a direct neighbor based on the >>> ] announcement of the 4-octet AS Capability allows a local speaker to >>> ] determine unequivocally whether the direct neighbor recognizes these >>> ] new attributes. Thus there is no need to examine the the attribute >>> ] flags (somewhat weaker indicator in this case) for that >>> ] determination. >>> >>> I think this is too vague: we should state clearly which flags are >>> to be checked. (I'm not sure what our consensus may be here.) >>> >>> Note also, that as a Normative reference, 4893bis would have to wait >>> for completion of draft-ietf-idr-optional-transitive before being >>> published. >>> >>> (BTW, the [OPT-TRANS] reference should clearly name the I-D title.) >>> >>> ] Given that the two-octet AS numbers dominate during the transition, >>> ] and are carried in the AS_PATH attribute by an OLD BGP speaker, in >>> ] this document the "attribute discard" approach is chosen to handle a >>> ] malformed AS4_PATH attribute. >>> >>> I think we could safely prescribe that without needing a Normative >>> reference... >>> >>> ] Similarly, as the AS4_AGGREGATOR is just informational, the >>> ] "attribute discard" approach is chosen to handle a malformed >>> ] AS4_AGGREGATOR attribute. >>> >>> Likewise. >>> >>> ] The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be >>> ] carried in an UPDATE message between NEW BGP speakers. A NEW BGP >>> ] speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR >>> ] attribute in an UPDATE message from another NEW BGP speaker MUST >>> ] discard the path attribute and continue processing the UPDATE >>> ] message. This case SHOULD be logged locally for analysis. >>> >>> No change. >>> >>> ] In addition, the path segment types AS_CONFED_SEQUENCE and >>> ] AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute >>> ] of an UPDATE message. A NEW BGP speaker that receives these path >>> ] segment types in the AS4_PATH attribute of an UPDATE message from an >>> ] OLD BGP speaker MUST discard these path segments, >>> >>> No change. >>> >>> ] adjust the relevant attribute fields accordingly, >>> >>> IMHO, this is too vague (but I don't have text to propose). >>> >>> ] and continue processing the UPDATE message. This case SHOULD be logged >>> ] locally for analysis. >>> >>> No change. >>> >>> ] The AS4_PATH attribute in an UPDATE message SHALL be considered >>> ] malformed under the following conditions: >>> ] >>> ] - the attribute length is not a multiple of two, or is too small >>> ] (i.e., less than 6) for the attribute to carry at least one >>> ] AS number, or >>> ] >>> ] - the path segment length in the attribute is either zero, or >>> ] is inconsistent with the attribute length, or >>> >>> No change. >>> >>> ] - the path segment type in the attribute is not one of the >>> ] types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE >>> ] and AS_CONFED_SET. >>> >>> No specific change, but I'm not clear on this: it seems to complicate >>> the introduction of new path segments (for all I know, there may already >>> be some in the wild). We have no language in 4893bis to require stripping >>> these when creating an AS4_PATH. >>> >>> ] A NEW BGP speaker that receives a malformed AS4_PATH attribute in an >>> ] UPDATE message from an OLD BGP speaker MUST discard the attribute, >>> ] and continue processing the UPDATE message. The error SHOULD be >>> ] logged locally for analysis. >>> ] >>> ] The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered >>> ] malformed if the attribute length is not 8. >>> ] >>> ] A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute >>> ] in an UPDATE message from an OLD BGP speaker MUST discard the >>> ] attribute, and continue processing the UPDATE message. The error >>> ] SHOULD be logged locally for analysis. >>> >>> No change. >>> >>> ] 7. Transition >>> >>> I think this section could be shortened. >>> >>> ] The scheme described in this document allows a gradual transition >>> ] from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one >>> ] Autonomous System or one BGP speaker at a time. >>> >>> Is this needed? >>> >>> ] To simplify transition, this document assumes that an Autonomous >>> ] System could start using a 4-octet AS number only after all the BGP >>> ] speakers within that Autonomous System have been upgraded to support >>> ] 4-octet AS numbers. >>> >>> Is this needed? What happens if the condition isn't met? >>> >>> ] An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System >>> ] number. >>> >>> Is this needed? We have no way to enforce it. >>> >>> ] A non-mappable 4-octet AS number cannot be used as a "Member AS >>> ] Number" of a BGP Confederation until all the BGP speakers within the >>> ] Confederation have transitioned to support 4-octet AS numbers. >>> ^^^^^^^ >>> Change to "32-bit" >>> >>> ] In an environment where an Autonomous System that has OLD BGP >>> ] speakers peers with two or more Autonomous Systems that have NEW BGP >>> ] speakers and use AS_TRANS (rather than having a globally unique AS >>> ] number), use of Multi-Exit Discriminators by the Autonomous System >>> ] with the OLD speakers may result in a situation where Multi-Exit >>> ] Discriminator will influence route selection among the routes that >>> ] were received from different neighboring Autonomous Systems. >>> >>> I think this says the OLD BGP speaker cannot distinguish MEDs. We >>> have no way to enforce any behavior on OLD speakers, so if we say >>> anything here, it must be about what NEW speakers would do. I don't >>> know what to suggest. (Is this needed?) >>> >>> ] Under certain conditions, it may not be possible to reconstruct the >>> ] entire AS path information from the AS_PATH and the AS4_PATH >>> ] attributes of a route. This occurs when two or more routes that >>> ] carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, >>> ] and the AS4_PATH attribute of at least one of these routes carries at >>> ] least one 4-octet AS number (as oppose to a 2-octet AS number that is >>> ] encoded in 4 octets). >>> ] When such aggregation results in creating a >>> ] route that is less specific than any of the component routes (route >>> ] whose Network Layer Reachability Information (NLRI) covers NLRI of >>> ] all the component routes), loss of the AS path information does not >>> ] create a risk of a routing loop. In all other cases, loss of the AS >>> ] path information does create a risk of a routing loop. >>> >>> Duplicate text, not needed here. >>> >>> ] When such aggregation results in creating a >>> ] route that is less specific than any of the component routes (route >>> ] whose Network Layer Reachability Information (NLRI) covers NLRI of >>> ] all the component routes), loss of the AS path information does not >>> ] create a risk of a routing loop. In all other cases, loss of the AS >>> ] path information does create a risk of a routing loop. >>> >>> If we're going to say anything about routing loops, I believe we >>> need to define "routing loop" and "forwarding loop"; and I'd strongly >>> recommend putting this in a different section. >>> >>> 8. IANA Considerations >>> >>> ] This document expands the pool for AS numbers from 0 - 65535 to 0 - >>> ] 4294967295. The AS numbers are managed by the IANA "Autonomous >>> ] System Numbers" registry. Other than expanding the AS number pool, >>> ] this document does not propose any modifications to the existing >>> ] policies and procedures pertaining to the AS number allocation. >>> >>> Delete. (already done, no IANA action needed) >>> >>> ] This document uses a BGP Capability code to indicate that a BGP >>> ] speaker supports the 4-octet AS numbers. The Capability Code 65 has >>> ] been assigned by IANA per [RFC5492]. >>> >>> No change. >>> >>> ] In addition, this document introduces two new BGP optional transitive >>> ] attributes, and their type codes have been assigned by the IANA. The >>> ] first one is the AS4_PATH attribute, value 17, which preserves the AS >>> ] path information with 4-octet AS numbers across old BGP speakers. >>> ] The second one is the AS4_AGGREGATOR attribute, value 18, which is >>> ] similar in use to the current AGGREGATOR attribute, but it carries a >>> ] 4-octet AS number. >>> >>> Delete. (already done, no IANA action needed) >>> >>> ] Finally, this document introduces a reserved 2-octet AS number -- >>> ^^^^^^^^^^ >>> Change to "describes the use of" >>> >>> ] AS_TRANS. The AS number 23456 has been assigned by the IANA for >>> ] AS_TRANS. >>> >>> Add: "IANA will need to update the 16-bit AS number registry to >>> point to this document. >>> >>> ] 9. Security Considerations >>> >>> A separate issue, not covered in this email... >>> >>> -- >>> John Leslie >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >> From raszuk@cisco.com Thu Jun 30 14:56:31 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1632F11E80E5 for ; Thu, 30 Jun 2011 14:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4Ar21TIV96m for ; Thu, 30 Jun 2011 14:56:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id A50E511E80CB for ; Thu, 30 Jun 2011 14:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=900; q=dns/txt; s=iport; t=1309470990; x=1310680590; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=shFISU74eFKYk8RmRweNXDmnQPWwy0ikpUAc/QW7D7o=; b=JJ2ikwVKL73vDnVsSG2dywtTZxpoYCbeuH2W4BGdQWqQgIDPoeaHWKOD w51MhHDNuQPf8fw1lcDmRUga60c/WGB/MzIiUWfUZYg4JxId/Nrrmcrhs P+QUhAKP8r/oNlJCYUMTGyL1qyLvqpinQvg9ZE35k12BIpVZ6dq/2NDfj c=; X-IronPort-AV: E=Sophos;i="4.65,454,1304294400"; d="scan'208";a="473079540" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2011 21:56:30 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ULuS5g023512; Thu, 30 Jun 2011 21:56:29 GMT Message-ID: <4E0CF10E.5050302@cisco.com> Date: Thu, 30 Jun 2011 23:56:30 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: John Scudder References: <20101018152745.GT82074@verdi> <4E091B54.4090008@cisco.com> <66F06B41-31DE-4921-84E8-0E54D70B464D@juniper.net> In-Reply-To: <66F06B41-31DE-4921-84E8-0E54D70B464D@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" , John Leslie , "quaizar.vohra@gmail.com" Subject: Re: [Idr] WGLC for draft-ietf-idr-rfc4893bis-03.txt, BGP Support for Four-octet AS Number Space X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:56:31 -0000 Hi John, > " 32-bit AS number > " An Autonomous System number in the range 65535-4294967295, as assigned > " by IANA in the "32-bit Autonomous System Numbers" registry. > ... > " 4-octet AS number > " The representation of AS numbers as defined in this document for NEW > " BGP speakers, using 4 octets to hold a 32-bit unsigned number, with > " high-order octets coming first. > > Basically this is a distinction between the number space and its representation. I think all specs use the notation of octets when defining the protocol extensions to carry some values. Yet unlike in John L's definition 4 octets is not the "wire" representation. We just send bits regardless how they are defined in the rfc. IMHO the spec is very clear as written and mixing bits and octets to essentially mean the same would only generate the confusion for the reader. Best regards, R. From keyupate@cisco.com Thu Jun 30 15:05:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0211E81BD for ; Thu, 30 Jun 2011 15:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWuVZT2IiV8w for ; Thu, 30 Jun 2011 15:04:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id BD80711E80E5 for ; Thu, 30 Jun 2011 15:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=4451; q=dns/txt; s=iport; t=1309471480; x=1310681080; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=BLyrqbLMfk+wVArJzzbyTdnL6JDopkbGDI1UNATe1zY=; b=Ba43PjOJhVE/EpR/i1BGGfusR+k3Zm5trivqcH8CfWkNT14XF6ugNrys FxcI/3mOAE0A0W/VFrHFtMCfvOgf1MpCdMk9q7089NXJzb2vUhE3BfMZs ksdBuLBHYDnNzgSuwOne4XmN+bGKigdcJ6HNwXVqbcBLU453huIU2nYsi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAP7xDE6rRDoH/2dsb2JhbABRmCmPM3eIeKEenWWGMQSHQIpvhH+LTw X-IronPort-AV: E=Sophos;i="4.65,454,1304294400"; d="scan'208";a="725073396" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2011 22:04:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5UM4eNa026651; Thu, 30 Jun 2011 22:04:40 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 15:04:39 -0700 Received: from 10.21.68.227 ([10.21.68.227]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 22:04:38 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 30 Jun 2011 15:03:00 -0700 From: Keyur Patel To: , Message-ID: Thread-Topic: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt Thread-Index: Acw2eRRJWAhmePI8S9uK7kMtK6DlbAAsJJrQABH0ws0= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 30 Jun 2011 22:04:39.0680 (UTC) FILETIME=[B5247800:01CC3771] Cc: idr@ietf.org Subject: Re: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 22:05:01 -0000 Hi Bruno, Thanks for the review. :) Comments are inlined. #Keyur On 6/30/11 8:11 AM, "bruno.decraene@orange-ftgroup.com" wrote: > Keyur, Enke, Rex, John, >=20 >> FYI. Will appreciate your comments. >=20 > Please find below some comments on your draft. >=20 > 5. Operation >=20 > 1) "Once the acknowledgment from a > peer is not received within the specified upper bound, and the > maintained state is compromised, then the speaker MUST clear the "TX > Routing State" in the GR Capability to be advertised to the peer in > the next session restart." >=20 > Is there a chance to be able to achieve a resync some time later within t= he > same BGP session? E.g. if latter on we receive an acknowledgement, is it > possible to start again sending a new version number & maintaining the > required state? If so IMHO it could useful to say so since current senten= ce > could be understood as prohibiting this ("MUST clear the "TX Routing Stat= e" in > the GR Capability to be advertised to the peer in the next session restar= t.") >=20 #Keyur: If the maintained state is compromised (e.g wrt Withdrawals) then you want to re-announce complete BGP table. >=20 > 2) " During the lifetime of an established session, if needed, a BGP > speaker MAY use the UPDATE-VERSION message to request updates from > the last update version that was previously acknowledged as long as > the speaker has received the Enhanced GR Capability from its peer. >=20 > When a BGP speaker receives such a request, it SHALL try to send > routing information from the last acknowledged update version that > the speaker has recorded. If the speaker is unable to do so for some > reason (e.g., "slow peer"), then it SHOULD perform a route refresh > using mechanism defined in [EH-RR] if possible. Otherwise, the BGP > speaker SHOULD reset the session." >=20 > - I would propose to add the following example as reason for not being ab= le to > send the routes "did not maintained required states") > - By "reset the session" do you mean sending a NOTIFICATION or initiating= an > OPEN with GR enabled? (I understand the former, why not using/allowing th= e > latter?) #Keyur: Notifications are fine as well as long as you have them on GR (draft-keyupate-idr-bgp-gr-extension). In any case we can provide a bit more clarification in the next rev. Regards, Keyur >=20 > Thanks > Regards, > Bruno >=20 > --------------- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enk= e > Chen > Sent: Wednesday, June 29, 2011 6:26 PM > To: idr@ietf.org > Cc: Keyur Patel > Subject: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt >=20 > FYI.=A0 Will appreciate your comments. >=20 > Regards,=A0=A0 -- Enke >=20 > -------- Original Message -------- > Subject:=20 > I-D Action: draft-keyur-idr-enhanced-gr-00.txt > Date:=20 > Wed, 29 Jun 2011 09:21:21 -0700 > From:=20 > internet-drafts@ietf.org > Reply-To:=20 > internet-drafts@ietf.org > To:=20 > i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Accelerated Routing Convergence for BGP Graceful Restar= t > Author(s) : Keyur Patel > Enke Chen > Rex Fernando > John Scudder > Filename : draft-keyur-idr-enhanced-gr-00.txt > Pages : 9 > Date : 2011-06-29 >=20 > In this document we specify extensions to BGP graceful restart in > order to avoid unnecessary transmission of the routing information > preserved across a session restart, thus accelerating the routing > convergence. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt