The approach as I understand it is two deploy multiple channels to disseminate routing state be it the 2,3,...nth path to some dest D.. Comments follow... Jim Uttaro Section 1.0 "The parallel route reflector planes solution brings very significant benefits at a negligible capex and opex deployment price as compared to the alternative techniques" A number of points need to be clarified here. The first is the SP/Operator needs to deploy n number of RR planes to disseminate N paths. Assuming some form of redundancy we would have to of course buy the RRs or deploy some type of logical routers. How can this be monetized? Does this approach assume that customers who want fast restoration, load balancing, mitigation of oscillation would pay for this. Or does the draft assume that the addl RRs are of such negligible capex cost that the operator would simply incur the cost.. This model does not usually sit well with the folks that write the checks. From an opex perspective we are putting in addl planes for each AS that is under the operators authority. So we not only need to pay for it we would need to establish coherent inter-AS strategies to manage, maintain these addl RRs.. Additionally the function of these devices is different than a traditional RR which implies that OpS needs to be cognizant of the difference and how they should be managed.. As described in the draft the 2,3..nth plane need not be as robust as it is not the primary path.. This needs to be understood by OpS in terms of their response to failure or how to perform maintenance.. We are essentially introducing a new device from these perspectives... Section 2.1 "This new requirement has its own memory and processing cost. Suffice to say that by the middle of 2009 none of the commercial BGP implementation can claim to support the new add-path behaviour in production code, in part because of this resource overhead." A bit confused by this statement.. My thoughts on this was add-paths is useful for a customer that is advertising multiple paths or at peering points. In both cases we would anticipate the use of routing policy to only select a subset of these routes. It is impractical to believe that we are going to duplicate the same state over and over again on each plane.. This is not a function of the draft but how operators deploy the functionality..This functionality has been around a long time in VPNV4 services and I believe it will eventually be used for IPV4 services.. " The add paths protocol extensions have to be implemented by all the routers within an AS in order for the system to work correctly." Pls explain.. Why do you believe this? It is certainly not practical and I never envisioned a full upgrade across thousands of edges in multiple AS domains.. The approach we believe we could take is to deploy on a subset of edges for some set of routes. " It is intended as a way to buy more time allowing for a smoother and gradual migration where router upgrades will be required for perhaps different reasons. It will also allow the time required where standard RP/RE memory size can easily accommodate the associated overhead with other techniques without any compromises.' His statement seems to conflict with the one above.. Above you state that it is needed everywhere to work correctly here the statement is we can buy time to gradually migrate.. Why don't we just gradually migrate and eliminate this middle step?? Section 4 " The proposed solution is based on the use of additional route reflectors or new functionality enabled on the existing route reflectors that instead of distributing the best path for each route will distribute an alternative path other then best. " Would like to drill down on this a bit..In the first case where addl deployment of RRs are done I am assuming that these RRs would somehow prefer the second best path of the first.. How would this be done customers use many different mechanisms to identify primary, secondary, etc... AS-PATH prepend, Local Pref, IGP cost etc... are all used..How is this done on the secondary plane? Regardless of either of these approaches changes to the BGP implementation to select a different POI is needed. But where how do you know how a customer is identifying? Pls expand on this. It would seem that although the protocol definition does not change the operator needs to ensure that this functionality is constructed the same way across all the vendors.. Will this require another draft? " The best path (main) reflector plane distributes the best path for each route as it does today. The second plane distributes the second best path for each route and so on. Distribution of N paths for each route can be achieved by using N reflector planes." How is this done when it is the IGP cost that is the deciding factor.. Will we have to correctly place the Nth plane corresponding to IGP correctly in the IGP?? " It is easy to observe that the installation of one or more additional route reflector control planes is much cheaper and an easier than the need of upgrading 100s of routers in the entire network to support different protocol encoding." See Above I do not believe it is all or nothing.. " Diverse path route reflectors need the new ability to calculate and propagate the Nth best path instead of the overall best path. An implementation is encouraged to enable this new functionality on a per neighbor basis." Encouraged? I think it would be required.. Section 4.1. Co-located best and backup path RRs "To simplify the description let's assume that we only use two route reflector planes (N=2). When co-located the additional 2nd best path reflectors are connected to the network at the same points from the perspective of the IGP as the existing best path RRs.' Based upon implementation this may require ports on existing core router to terminate and a costing paradigm that duplicates the original the latter may be simple the former would require that there is availability at these locations.. Doesn't this also imply full symmetry? We could not deploy a subset for the nth plane and mimic the IGP decision making of the first?? The draft states that full symmetry is not needed.. Pls Clarify.. " One of the deployment model of this scenario can be achieved by simple upgrade of the existing route reflectors without the need to deploy any new logical or physical platforms. Such upgrade would allow route reflectors to service both upgraded to add-paths peers as well as those peers which can not be immediately upgraded while in the same time allowing to distribute more than single best path." The implication here is that the same primary RR would have to "hold" and disseminate multiple paths to D.. Would this create a scalability problem on this RR as it would have to hold these addl routes. Even though the number of BGP routes for the internet is small in comparison to VPNV4 this should be accounted for when RR platforms are selected. "The way to accomplish this would be to create a separate IBGP session for each N-th BGP path. Such session should be preferably terminated at a different loopback address of the route reflector. At the BGP OPEN stage of each such session a different bgp_router_id should be used. Correspondingly route reflector should also allow its clients to use the same bgp_router_id on each such session." We need simple deployment strategies. Section 4.2. Randomly located best and backup path RRs " The basic premise of this mode of deployment assumes that all reflector planes have the same information to choose from which includes the same set of BGP paths. It also requires the ability to skip the comparison of the IGP metric to reach the bgp next hop during best-path calculation." Scalability concerns. We would be putting our main primary RRs at risk. Again I am confused about the IGP metric.. If the paths are equal up to the IGP metric how do decide which is primary/secondary.. The secondary RR needs to select one of the paths how does it do that??Is it router-id or something of that nature.. "4. Fully meshing newly added RRs' with the all other reflectors in both planes. That condition does not apply if the newly added RR'(s) already have peering to all ASBRs/PEs." I cannot see creating BGP sessions to all ASBR/PEs. There are BGP session limits that also must be accounted for so I do not see that as a viable alternative in a large network.. So I guess we would have to fully mesh to all RRs. This is similar to a full mesh of PEs in terms of getting all the routes on the secondary to make a decision. " Any of the existing routers that are not already members of the best path route reflector plane can be easily configured to serve the 2nd plane either via using a logical / virtual router partition or by local implementation hooks." The term "Easily" is used to liberally. Getting complex functionality configured on our most important parts of the network is never easy. It requires a lot of test certification and coordination between OpS, maintenance, etc... to get deployed " The additional planes of route reflectors do not need to be fully redundant as the primary one does. If we are preparing for a single network failure event, a failure of a non backed up N-th best-path route reflector would not result in an connectivity outage of the actual data plane. The reason is that this would at most affect the presence of a backup path (not an active one) on same parts of the network. If the operator chooses to build the N-th best path plane redundantly by installing not one, but two or more route reflectors serving each additional plane the additional robustness will be achieved." Yes that may be true but we envision add-paths as being functionality that not only enables fast restoration but the ability to provide customer with load balancing. Probably good to be specific about the goals of the draft in the intro/abstract. Section 4.3. Multi plane route servers for Internet Exchanges " In such cases 100s of ISPs are interconnected on a common LAN. Instead of having 100s of direct EBGP sessions on each exchange client, a single peering is created to the transparent route server. The route server can only propagate a single best path. Mandating the upgrade for 100s of different service providers in order to implement add-path may be much more difficult as compared to asking them for provisioning one new EBGP session to an Nth best-path route server plane." I do not understand. Are you saying that each eBGP session is nailed up to each plane. Are you implying that we deploy 100 planes? If not how do we know which one of the 100 ISPs should get the benefit of having routes source by them propagated through the network?? -----Original Message----- From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, June 23, 2010 4:30 AM To: i-d-announce@ietf.org Cc: grow@ietf.org Subject: [GROW] I-D Action:draft-ietf-grow-diverse-bgp-path-dist-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Global Routing Operations Working Group of the IETF. Title : Distribution of diverse BGP paths. Author(s) : R. Raszuk, et al. Filename : draft-ietf-grow-diverse-bgp-path-dist-01.txt Pages : 20 Date : 2010-06-23 The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined today BGP has no mechanisms to distribute paths other then best path between it's speakers. This behaviour results in number of disadvantages for new applications and services. This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes. It also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. The authors believe that the GROW WG would be the best place for this work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-diverse-bgp-path-dis t-01.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. _______________________________________________ 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
