Subject: [GROW] Last Call: <draft-ietf-grow-simple-va-08.txt> (Simple Virtual Aggregation (S-VA)) to Informational RFC

From: The IESG <[email-masked]>
Date: Tue, 29 May 2012 09:07:22 -0700

The IESG has received a request from the Global Routing Operations WG
(grow) to consider the following document:
- 'Simple Virtual Aggregation (S-VA)'
  <draft-ietf-grow-simple-va-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-06-12. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   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.  Simple Virtual
   Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that
   allows any and all edge routers to shrink their RIB and FIB
   requirements substantially and therefore increase their useful
   lifetime.

   S-VA does not increase FIB requirements for core routers.  S-VA is
   extremely easy to configure considerably more so than the various
   tricks done today to extend the life of edge routers.  S-VA can be
   deployed autonomously by an ISP (cooperation between ISPs is not
   required), and can co-exist with legacy routers in the ISP.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-grow-simple-va/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-grow-simple-va/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 01 Jun 2012 00:47:59 +0200

Hi SM,

Very good catch ... repurposing APNIC IPv4 address space was not 
intended. Simply the address space in the example was chosen completely 
randomly.

I will remove that text from the final version of the document.

Thank you very much for your review,
R.

> At 09:07 29-05-2012, The IESG wrote:
>
> As a nit:
> "Generally, any more specific route which carries the same next hop as
> the VA-prefix 0/0 is eligible for suppression. However, provided
> that there was at least one less specific prefix (e.g., 1.0.0.0/8)
> and the next-hop of such prefix was different from that of the VA
> 0/0, those more specific prefixes (e.g., 1.1.1.0/24) which are
> otherwise subject to suppression would not be eligible for
> suppression anymore."
>
>  From APNIC:
>
> inetnum: 1.1.1.0 - 1.1.1.255
> netname: Debogon-prefix
> descr: APNIC Debogon Project
> descr: APNIC Pty Ltd
>
> Is there a reason why the Global Routing Operations WG is repurposing
> APNIC IPv4 address space in this draft?
>
> Regards,
> -sm
>
>

---

From: SM <[email-masked]>
Date: Thu, 31 May 2012 15:25:10 -0700

As a nit:

 From APNIC:

Regards,
-sm