Subject: Re: [GROW] I-D Action:draft-ietf-grow-va-04.txt

From: "George, Wes E [NTK]" <[email-masked]>
Date: Thu, 17 Mar 2011 14:14:41 +0000

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-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, February 22, 2011 8:00 AM
To: [email-masked]
Cc: [email-masked]
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.