Re: [Idr] draft on virtual aggregation

In message <37BC8961A005144C8F5B8E4AD226DE1109D823@EXCHANGE2.cs.cornell.edu>
Paul Francis writes:
>  
>  
> Gang,
>  
> At the following URL is a draft on virtual aggregation that I'm posting to
> IETF (it'll show up in a day or two), and which I'll present at IDR in
> Dublin.  
>  
>  http://www.cs.cornell.edu/people/francis/draft-francis-idr-intra-va-00.txt
>  
> Title and abstract are below.  I hope to create a work item on this in IDR.
> I would characterize this as falling under the general charter of scaling
> BGP.
>  
> Any comments and discussion on this prior to Dublin is of course greatly
> appreciated.
>  
> PF
>  
>  
> Title:  Intra-Domain Virtual Aggregation
>  
>  
>    Virtual Aggregation (VA) is a technique for shrinking the DFZ FIB
>    size in routers (both IPv4 and IPv6).  This allows ISPs to extend the
>    lifetime of existing routers, and allows router vendors to build FIBs
>    with much less concern about the growth of the DFZ routing table.  VA
>    does not shrink the size of the RIB.  VA may be deployed autonomously
>    by an ISP (cooperation between ISPs is not required).  While VA can
>    be deployed without changes to existing routers, doing so requires
>    significant new management tasks.  This document describes changes to
>    routers and BGP that greatly simplify the operation of VA.
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

Paul,

Is there a need?

  Are we still trying to do the equivalent of keeping an AGS+ with
  DFRT alive somewhere?  RAM is cheap and dense.  To get to on-chip
  RAM would require orders of magnitude reductions in DFRT size.

  Other techniques exist for dramatically reducing core router FIB
  size if that becomes a goal for a provider.

  For example, MPLS (or GRE) tunneling through a BGP free core reduces
  FIB size to about the size of the IGP (should easily fit in on-chip
  memory).  It requires no protocol change.  Only down side is no ICMP
  when tunnel faults in middle prior to the ingress knowing about it
  (usually the case anyway due to VPN and VRF) and no fallback to IP
  when ingress knows that the tunnel is down and hasn't yet rerouted.

Is the solution worse than the problem?

  This seems too operationally problematic.

Curtis
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr