Re: [GROW] I-D Action: draft-ietf-grow-diverse-bgp-path-dist-05.txt

["George, Wesley" <[e-mail]>]

I've read this draft. I'll note that I'm already in the acknowledgements section, but I can't find an on-list review that I wrote on this draft prior to this point unless I sent it privately to the authors, in which case I apologize if I'm retreading old discussion.
A nit regarding the acknowledgement - my first name is Wes, not George.

Some Nits
Abstract: %s/build/built in parallel, /co-exit/co-exist
Now that the draft is a WG doc, "..the authors believe..." (last sentence) can probably be removed (from intro section as well).

Intro: "other then best path" - suggest rewording to something like "secondary and tertiary paths" or "alternate paths which are not considered best path"

2. %s/"reduction of time of reachability restoration"/faster reachability restoration

Other stuff:
2.1 - when discussing overhead and scale concerns for add paths, perhaps a citation to 4984 would be appropriate? I've made similar comments to the SIDR folks, and I think generally anything that adds a non-trivial amount of impact to the growth curve of the routing system needs to consider this. Also, why is this citing implementation data from 2009? Is there now an implementation that supports add-paths, or is this just a holdover from earlier versions of the draft? If there is now an implementation, it would be good to revisit this section.

4. This asserts that no code changes are necessary to RR clients. I'm not sure I totally agree with that... If the idea is to have a primary (best) RR and then N additional paths, the general assumption is that the N, N1, ... RRs are carrying routes that are less and less preferred. How does this system avoid the same sort of inconsistency of best path choice among different routers in the network if there is no way to identify those paths as secondary? I think you need some way to determine if the alternate routes are intended to be ECMP routes or backup routes...
You may be able to cover this without code changes by using alternate configurations of other BGP preference indicators (MED, Localpref, metric, etc), perhaps with inbound route policy on the client or outbound on the RR, but since things like metric may be different based on where something is in the network, that may lead to inconsistency if used by itself. Even then, the draft doesn't discuss how this should be managed.

4.1 Also, there's a definite scaling consideration on the RR clients that isn't really discussed here - they are now going to be storing some number of additional routes and paths that is linearly related to the number of additional planes that are implemented. The addition of more RR sessions that presumably carry a portion of the full routing table now drives a non-trivial increase in memory footprint and processing overhead (and potentially convergence time for slower boxes). In the simplest case of 2 primary route-reflectors (for diversity), and 1 2nd-best path RR, you've added one session. If you want to carry a 3rd-best RR or have redundant 2nd-best RRs, you've added 4 sessions. It's fair to say that after a certain number of alternate paths, you start having less routes because there are only so many alternative exits, but otherwise there is a potentially large problem even if it's not quite as bad as addpaths.
I might recommend that you do some analysis of the routing table to know where this threshold makes a difference, based on how many alternate paths an average route carries. In addition to being a scaling consideration, it also helps to inform what value of N becomes diminishing returns because most networks don't have that many backup paths. I envision this being something like "80% of routes have 4 or less paths, so moving beyond 4 planes may add overhead without much benefit..."

Further scaling considerations occur in the core if the P routers must know about both the primary and secondary paths (and therefore peer/mesh with both R1 and R1'). You may be able to draw the conclusion that this is better than full mesh (5.1 #3) and therefore superior from a scaling perspective, but this at least needs to be discussed. It may be that the only way to avoid that particular issue is to operate with a BGP-free core...

It may be appropriate to add a separate scaling considerations discussion to your deployment considerations (section 6) to discuss some of the above.

There may be additional operational considerations from the perspective of route analysis - if you have either a homebuilt or off the shelf set of software that does route analysis for the purpose of event root-cause analysis, anomaly detection, capacity planning/failure analysis, etc, it has to be aware of these additional planes such that it returns the proper response when evaluating the routing table to determine what the expected behavior should be in the real network. This is especially important when it uses the table to determine how traffic will reroute during different failure scenarios. These tools may act like a participant in the mesh rather than a client in order to get a pure view of the table, and that may lead to undesired results if the multiple planes aren't taken into account. There may also be considerations for looking glass implementations and the actual information that is visible on the RRs and RR clients as the result of standard BGP show commands to aid in troubleshooting and verification.

Thanks,

Wes George

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, September 15, 2011 9:58 AM
To: [e-mail]
Cc: [e-mail]
Subject: [GROW] I-D Action: draft-ietf-grow-diverse-bgp-path-dist-05.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)       : Robert Raszuk
                          Rex Fernando
                          Keyur Patel
                          Danny McPherson
                          Kenji Kumaki
        Filename        : draft-ietf-grow-diverse-bgp-path-dist-05.txt
        Pages           : 22
        Date            : 2011-09-15

   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 its 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.
   Such planes can be build in parallel or they can co-exit on the
   current route reflection platforms.  Document 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-dist-05.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-grow-diverse-bgp-path-dist-05.txt
_______________________________________________
GROW mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/grow

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.