[Idr] draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt
Robert Raszuk <raszuk@cisco.com> Sat, 04 June 2011 22:51 UTC
Return-Path: <raszuk@cisco.com>
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 <idr@ietfa.amsl.com>; 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 <idr@ietfa.amsl.com>; 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 <idr@ietf.org>; 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 <idr@ietf.org>; 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 <raszuk@cisco.com>
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" <idr@ietf.org>
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 <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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.
- [Idr] draft-vinod-lavallee-bgp-optimal-route-refl… Robert Raszuk
- Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-… Jeff Tantsura
- Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-… Vinod Joseph
- Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-… Robert Raszuk
- Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-… Robert Raszuk
- Re: [Idr] draft-vinod-lavallee-bgp-optimal-route-… Vinod Joseph