As requested by the authors, I have completed a review of this document. I think that the idea is sound, but I believe that the drafts need some more work.
A general comment - you probably need to consider the work going on in SIDR and discuss any potential interactions. I know that VA doesn't change BGP behavior, but given that SIDR has provision to allow for certain routes to be preferred by policy based on a set of validation criteria, it would be worth discussing how the two would work together without interference, especially since one of the use cases for SIDR is to do validation and apply policy at the ASBR that is carried throughout the ASN in iBGP. Regarding "VA has the following characteristics..." in the Intro - maybe I'm nitpicking, but these are really more design goals. It's incumbent upon you to prove that these design goals are met by the proposed implementation. 1.3 Terminology: Your definition of Tunnel and the specification of MPLS is a bit unclear. If this implementation is truly agnostic to the type of tunnel, then leave it at that. IMO, it would be better to discuss VA in terms of generic tunnels throughout the draft, and then have a section or a companion draft specifically related to implementing using MPLS tunnels, as well as any optimizations that can be used as a result. Section 2 - "..core routers would maintain full FIBs..." You should consider discussing alternate implementations such as lean/hollow core, where there really isn't a core with a full FIB anymore. This is a different use case, I think VA is still applicable, but I think it's going to become more common. 3.1.2.1 - "...non APR routers MUST know which prefixes are VPs before they receive routes for those VPs..." - I'm not sure that this is a MUST. While you're right in mentioning the consequence of unnecessarily filling the FIB with routes they don't need, this isn't a requirement for the protocol to work. It's just a recommended safeguard to prevent VA routers from having FIB capacity problems during convergence. Static VP list - I understand the MUST here, but I think you need an alternative to static configuration, especially if VPs are defined more dynamically based on a set of policies. Perhaps a recommendation for a means to sync with a central file (via SCP, for example), or a recommendation to leverage the machinery built into many router OSes now that allows you to prioritize convergence of a certain set of prefixes over another to ensure that you don't end up converging twice - once normally, and a second time as you get the routes for VPs. 3.1.2.2 - "it is important that VPs not be advertised across AS boundaries" - There should be a MUST here. You cover this in 3.2.1.3 as identifying these with the well-known no-export community, but I think this section has a missing normative. 3.1.5 #1 - "if there is an alternate route to the sub-prefix for which there is a tunnel, then that route SHOULD be selected, even if it is less attractive according to the normal BGP best path selection algorithm" - This is unclear to me. You state earlier in the document that VA does not interfere with BGP's normal operation, nor require any changes to BGP, which I assume to include path selection. Therefore you would need to recommend some sort of policy-level configuration to ensure that the route you say SHOULD be selected is never "less attractive according to the normal BGP best path selection algorithm" 3.1.5.1 dynamically identifying high-volume prefixes - There needs to be some best common practice recommendations for using this, and you probably also need to think about a damping mechanism to prevent oscillation in the case of bursty traffic (assuming oscillation is an undesired effect...). When I say bursty traffic here, I understand that over a period of days, a lot of bursts may smooth out, but there may still be certain types of traffic/hosts that are bursty over that period - they hit due to some trigger, but are gone the day after. "The downside...complicates debugging..." - you should recommend a method for logging dynamic changes to a server. It might be possible to use common BGP listener systems to just log the routing table on a given router, but it might also make sense to define a lightweight syslog entry to identify what prefixes are being added or removed along with a timestamp. 3.2 - #1 "expect operator groups like NANOG to compile good VP-lists" - I'm not comfortable with this recommendation as it stands currently. Every ISP is different, and I highly doubt that there's going to be much in terms of one-size fits all applications of VA. I think I would rather see a section of this draft or a separate draft with a BCP around how to compile good VP-lists that could be used to write a route-analysis tool to generate VP lists based on the specific network to which VA is being applied. If someone chooses to apply that and generate a more generic Spam blacklist-style VP list that they publish for others to use, that's fine, but that shouldn't necessarily be the recommendation in this draft. #2 - "first, there must be enough APRs...failure scenarios" - you need to discuss the potential failure scenarios and adequately define "enough" "APR assignment should not result in router overload" - how are you defining overload in this case? Too much traffic? Too many routes in FIB? Please be specific. "particularly long paths..." - again, please define specifically what you are asking to be avoided This entire section also has a lot of normative words (shoulds, mainly) that are not capitalized - suggest rewording to eliminate the confusion if these are not meant to be normatives. 4.2 - use of inner label - my comments about MPLS apply here as well - either this is agnostic to tunnel mechanism or it's not - your language here regarding the inner label isn't particularly clear on the benefits of doing this as a potential optimization that can be achieved by using MPLS tunneling instead of a different type. Hope this is helpful... Wes George -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, February 22, 2011 8:00 AM To: [email protected] Cc: [email protected] Subject: [GROW] I-D Action:draft-ietf-grow-va-04.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 : FIB Suppression with Virtual Aggregation Author(s) : P. Francis, et al. Filename : draft-ietf-grow-va-04.txt Pages : 24 Date : 2011-02-22 The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers, easily by an order of magnitude with negligible increase in path length and load. FIB suppression deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. There are no changes from the 03 version. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-va-04.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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
