[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Abstraction of problem space

Tony Li wrote:
Hi Brian, |And, specifically, an entity's apparent role needs to be able to be |ambiguous, simultaneously being at more than one level in the food |chain, and simultaneously having more than one "profile". |Especially when considered over a non-trivial period of time, i.e. the |lifetime of the entity. (By "entity" we can mean anything with a |routing policy, be it an ASN, ISP, site, host, or whatever.) 
|
|I fear that too many ideas being discussed, even in relatively |abstract |terms, don't take this into consideration, or are optimized for |instantaneous state ("snapshot"). 


I guess I'm not understanding your concern sufficiently.  An entity that
changes its role in a locator/identifer split architecture is able to change
its addressing at least as easily as it does today. Can you please be more specific? 

I'll try.

What I was thinking about was the PE/CE model of some solutions.
If a CE entity, for whatever reason, needs to become a PE, what happens then?
Currently, this would involve an entity with PA space from its upstream, having to get PI space and renumber.
Renumbering can be very time consuming and painful, and is thus a barrier to entry.
It may be the case that some proposed models (or solutions) don't make this any worse, but don't make it any better.
I'm suggesting that we give this consideration in identifying solutions to scaling, given that we are talking long term, which necessarily involves the long term for all of the users of the resulting architecture.
|BTW - the ability to take a piece of IPv4 PA space, and start |announcing |it as if it were PI space, is an example of the kind of thing |that needs |to be supported. 


In a locator/identifier architecture, you only advertise locators into
routing.  Whether you are an end site or a ISP is irrelevant.  There's no
need for the distinction between PA and PI, and frankly, the PI mode should
simply be eliminated to maximize aggregation.



Yes, I understand the locator part of the loc/id split being all PA.
I was thinking about the identifier portion of the split, and whether scalability on the combined system can benefit from aggregation, and if so, whether and how isolated portions of the EID space can be 
deaggregated at arbitrary boundaries.


|Changing the role of a "piece" of the Internet, without renumbering.


Without renumbering seems like an unnecessary and contradictory requirement.
One of the role changes that you might want to support is the migration from
having addresses within an upstream prefix to having a global, unaggregated
prefix.  Any such change is going to require renumbering *if you want to
maintain aggregation*.  Building in mechanisms that explicitly support
deaggregation is simply shooting ourselves in the foot.
I think this is one of those areas where some of the subtleties involved require great care in making distinctions, 
and perhaps even better terminology.

Aggregation depends on two things:

   * Addresses of "things to be aggregated" being suitably close
   * Topology permitting aggregation to occur without changing path
     selection policy
If we consider "longest match wins" logic, we can get benefits from aggregation even when more-specific prefixes 
continue to be part of the solution.
For example, having covering aggregates (permitting us to suppress a vast majority of covered prefixes) and also having more-specific prefixes (which constitute prefixes whose attributes differ from the covering aggregate), lets us reduce the number of prefixes, without necessarily reducing the number of prefixes to "1" (for the given range of prefixes).
The fact that such covering prefixes can be nested, means that even messy, complex prefix+policy combinations can be 
significantly reduced.
What matters most, is that aggregation is possible, and that for any location in the topology, that aggregation reaches a level where the resources (especially the FIB) required are not unreasonable.
If the above criteria can be met, while allowing localized deaggregation that does not impact global aggregation, then 
the deaggregation itself becomes mostly moot.

Here are some specific examples, and specific observations:

   * If an addressing scheme is primarily based on geographic
     information (e.g. latitude/longitude), then:
         o the further away a region is, the more likely aggregation
           over the regions' prefixes is possible
         o the immediate (local to a router) aggregation ability
           depends primarily on the number of egress links
         o while the number of prefixes over which aggregation may
           occur is a function of local conditions, the local diversity
           means aggregation is "self-similar":
               + the aggregation ratio is likely no worse, and may
                 improve, as the number of prefixes increases locally
   * If aggregation is performed locally during the mapping of RIB ->
     FIB, RIB size is less of a concern
   * Aggregation can be performed in multiple stages, in multiple
     locations; aggregation is always a monotonically decreasing function
   * If addressing is geographic, rather than topological (PA),
     aggregation can occur to a much larger degree, all the way down to
     a single "default" covering aggregate
   * The major concern with aggregation is not so much the generation
     of covering aggregates, as much as it is about the suppression of
     more-specifics
         o If suppression of more-specifics occurs primarily at the RIB
           -> FIB boundary, then PROXY aggregation itself becomes a
           reasonable mechanism for generating covering aggregates

One possible example solution, based on the above, is as follows:

   * EIDs are assigned geographically
   * Locators are assigned topologically (PA blocks from providers)
   * Aggregation occurs both on locators (PA space as it crosses
     provider boundaries), and on EIDs
   * EID->Locator mapping is done with routing
   * Every EID must have a next-hop that is a Locator
   * The proxy aggregation that occurs, covers sets of {EID->Locator}
     routes with one or more aggregate routes, [EID->Locator(ME)],
     where each Locator(ME) is the address of the router that performed
     the aggregation
   * Proxy aggregation and announcements of aggregates, needs to honor
     routing policy (specifically, ensuring that the customer vs peer
     vs transit provider relationship is not masked by aggregates
     and/or suppression of more-specifics)
   * ASBR routers will very likely need many more prefixs than non-ASBRs
   * ASBR FIB size will likely depend on both local out-degree,
     diversity of peer tiers, and diversity within each tier
         o aggregation should be inversely proportional to diversity
   * By using routing *as* the mapping function, there are several
     immediate benefits:
         o backward compatibilty is possible
         o incremental deployment is feasible
         o compatibility with existing hardware is automatic
         o no additional network elements are strictly necessary
         o no encapsulation means no MTU issues
         o no rewriting packets means no performance impact
         o all of the important changes can be handled in the control plane
         o by partitioning the routing space into EID and Locator,
           differential rules for prefix size can be maintained with
           relative ease
         o any other advancements that occur in routing protocols (esp.
           BGP) result in immediate benefits in this solution space
I know it goes a long way down one specific path (geographic addressing) that has yet to be suitably described, but I think the potential benefits are significant.
I'll discuss the details on aggregation with multiple nested covering aggregates in a separate thread. 

Brian


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg