Subject: [RAM] Distribution of pain and gain

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Mar 2007 23:46:26 +0200 (EET)

Hello all,

In order for any change to be relevant from the deployment 
perspective, it's crucial to examine which parties are having (most) 
pain and what is the associated deployment benefit.

  1) Big Tier1 and some Tier2 ISPs.  Dense iBGP meshing, VPN routes, TE
     deaggregates and DFZ contribute to a large number of RIB entries
     (even in the order of 1-2M+ with multiple paths) and FIB entries
     (even in the order of ~0.5M entries).

     Technical solutions ("newer hardware") exist to solve this problem
     but deploying it would be costly as most ISP-ISP edge routers
     would need to be updated.

     FIB/RIB sizes could be possibly somewhat reduced by centralizing
     computation (e.g., more route-reflectors).  Likewise, ISPs could
     employ stricter prefix-filtering (e.g., based on allocation
     boundaries unless explicitly agreed) and employ more
     locally-scoped ISP-ISP traffic engineering (e.g., agreed
     communities to affect lower/raise localpref, MED, NO-EXPORT
     community w/ more specifics) instead of balancing/adjusting
     traffic using e.g., deaggregation.

     These would make the network more difficult to operate though, and
     especially prefix-length restrictions would require significant
     maintenance.

     The bottom line from this perspective is that buying new routers
     (or trying to get the IETF to specify backwards-compatible RIB/FIB
     reduction mechanisms) is probably cheaper than changing the
     operational practices.

  2) Mid-sized ISPs.  These have significantly smaller number of
     RIB/FIB entries compared to big ISPs, and as such are mainly
     affected by very old hardware issues (e.g., 256K maximum
     prefixes).

     While some might find an architecturally cleaner solution
     preferable, the equipment will need to be replaced anyway and the
     solution could not be applied.  It is also not clear if such a
     solution would support the ISP's or their customers' TE
     requirements.

     It seems likely that from operational and business continuity
     perspective, just upgrading equipment is the safest choice.

  3) BGP-using endsites, smaller ISPs.  Getting an AS number and a
     routable IP prefix has become easier and easier.  Endsites do not
     feel any pain at present.  Many have full BGP feeds from their
     transit ISPs, but outbound traffic engineering could easily be
     achieved with a subset of DFZ or even default routes provided
     that the endsites connect to ISPs which provide reachability to
     everywhere (e.g. Tier2-3's who acknowledge being Tier2-3s)

     Given that only few upstream ISPs restrict prefix deaggregation,
     inbound TE can easily be achieved by polluting the DFZ.

     The bottom line is that endsites feel no pain, and as long as
     transit ISPs do not have stricter filters on accepted TE usage,
     endsites have no interest whatsoever to change their practices.

  4) Non-BGP using, possibly multihoming/connecting endsites (smaller
     enterprises, home users with DSL+cable, etc.).  This is a segment
     where SHIM6-like solutions are most applicable.  At the higher end
     of this niche (managed, but small enterprise network) there is
     some need for solutions which would avoid renumbering.

     It seems that architectural solutions here would be most
     applicable here, but would not be explicitly deployed even
     if such existed.  Support would need to be bundled together with
     either host upgrades or moderately-priced CPEs.

As a bottom line, big ISPs seem to be looking for software 
implementation or minor protocol enhancements to address the issues 
they are seeing.  Architectural solutions do not solve their 
short/mid-term problems and even if they did, the cost of upgrading 
equipment is likely smaller than getting required major new protocols 
deployed.  As soon as big ISPs *really* start to feel the pain, 
they'll either justify upgrades or start doing prefix etc. filtering.

Before prefix/update filtering starts to become enforced by bigger 
ISPs, there is zero incentive for smaller ISPs and endsites to change 
any of their operational practices, and there is no incentive to 
deploy solutions in this context.

There is potential area of work on non-BGP using endsites but doing 
anything there is not going to address FIB/RIB issues.  At best this 
could make it more lucrative for small sites to not go for a BGP-based 
solution if adequate solution exists (I argue that NAT/loadbalancer 
boxes in v4 probably already fill this gap), i.e., limit the 
BGP-endsite growth curve.

It will be interesting to see whether big ISPs will start to apply 
some prefix/update-filtering or just go for new hardware when they 
_really_ start feeling the pain.

Maybe the architecturally best end-game solution can be achieved if 
big ISPs will start prefix/update-filtering :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: [email-masked]
Date: Fri, 23 Mar 2007 18:13:34 EDT

>From ISPs you will never get a plan how to build a lung while they  know how 
to take in oxygen via the skin.
Obviously this email favors to keep up with BGP for ever, no matter how  
useless the worldwide UPDATE churn is. Right?
I do not mind at all that short-term solutions are considered as well,  e.g. 
inside idr.
 
Maybe the mailinglists should have a clear scope of objectives,e.g.
 
idr: BGP-based solutions
RAM: LISP 1.0,...,3.x
RRG: long-term only
 
Heiner

In einer eMail vom 23.03.2007 22:50:36 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hello  all,