Subject: Re: [rrg] moving towards recommendation: the current plan

From: Scott Brim <[email-masked]>
Date: Thu, 03 Dec 2009 11:03:58 -0500

Noel Chiappa allegedly wrote on 11/25/2009 2:08 PM:
>     > From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
> 
>     > I am left wondering how does the locator and identifier separation
>     > fit into the story line.
>     > ...
>     > They separation seems to be orthogonal to the aggregation based
>     > solutions.
> 
> No, because a lot of the routing-table entries which are appearing now are
> 'de-aggregates' caused by a number of things which separation of location
> and identity will give us additional tools to provide _without_ having to
> depend on the routing. 

Yes.

> (BTW, "locator and identifier" is not really optimal terminology, because
> those refer to specific kinds of names, and it's better to refer to the
> generic concepts, i.e. 'identity' and 'location'.)

Yes and even better is to talk about verbs instead of nouns.  That is,
the problem is not in the identities themselves ("Scott"), but in
identification _functions_ which misuse location-dependent information
("Ithaca" instead of "Scott").

> - Provider-independent addresses, which are inherently unaggregatable:
> with I/L separation, the PI addresses need not be advertized in the
> modified part of the network, only the location of the entry routers.

Unfortunately people also like PI addresses because of site renumbering
issues.  See below.

Joel M. Halpern allegedly wrote on 11/26/2009 2:49 AM:
> The separation of identity and location should mean, for example, that
> multi-homed sites can be properly aggregated in teh core routing table.
>  So the separation is distinctly applicable to multi-homed sites and
> their inter-domain aggregation.

I assume that "properly aggregated" means either PA addresses are used
inside the site or site addresses are not aggregated at all.
Location/identification separation is necessary but not sufficient.

Scott

---

From: Dan Jen <[email-masked]>
Date: Fri, 04 Dec 2009 00:14:26 -0800

Hi all,

On Thu, 2009-11-26 at 02:49 -0500, Joel M. Halpern wrote:
> One related side effect is that the mapping system can take 
> responsibility for providing traffic engineering information for such 
> sites, so that we do not have to use dis-aggregation for multi-homed 
> edge sites' traffic engineering.
> 

But even if traffic engineering is handled elsewhere, how much of
deaggregation is rooted at TE and how much for other reasons?  .  All of
the recent proposals and rrg discussion seem to focus on re-empowering
aggregation by attempting to pinpoint the reasons for deaggregation and
dealing with them.  A lot of reasons have been brought up, such as PI
usage, ingress TE, avoiding renumbering, etc.  Yet, it is unclear how
much each 'cause' contributes to overall deaggregation.   

I wonder if it would be preferred to have a solution that allows
networks to shield themselves from routing table bloat, regardless of
the causes behind long-prefix announcements - a cause-agnostic solution.

> While there have been some inter-domain variations on 
> virtual-aggregation suggested, the primary applicability of tat 
> technique is intra-domain.  While it has the potential (if we can
> deal 
> with configuration complexity and issues such as loose source policy 
> application) to provide a significantly larger than 30% win, it is
> still 
> largely a short term technique designed to help us keep functionaing 
> while we get to an architecture that works better.

I understand why local FIB aggregation is just a short-term solution,
but why do you consider VA a short-term solution?  According to the RRG
design goals draft, VA fits all the 'required' goals.  VA allows
networks to scale down their tables to any arbitrary size by
re-enabling aggregation within the network.  It's also
deployment-friendly.  

I can see why one would want to add to VA to achieve some of the
'strongly desired' goals, but I don't think VA should be considered
'short term', as it does help with our primary goals for the long haul.

Dan Jen