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

From: [email-masked] (Noel Chiappa)
Date: Wed, 25 Nov 2009 14:08:41 -0500 (EST)

> 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. (Remember Wheeler's/Lampson's famous aphorisms
about problems in computer science being solved by another layer of
indirection, i.e. binding - separation of location and identity gives us
just such a layer of binding.)

(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'.)

Here are some examples of things which are causing extra routing table
entries to appear, which can be done without those extra entries if there
is a identity/location binding layer:

- Injecting more-specifics into the external scope to cause inbound
traffic to take the optimal entry point: this can be down with I/L
separation by binding the addresses of different parts of the internal
scope to different entry routers (with others listed as lower-priority,
in case the prime router fails).

- Multi-homing, which causes what are effectively PI addresses (even if
allocated from one provider's block) to be advertized from routers
connected to other providers: again, with I/L separation, the different
entry routers can be listed in that block's binding, and only the location
of the entry routers (which can/should be given addresses from the block
of the provider to which they are attached) need be advertized -
aggregated, of course, into that provider's advertisement.

- 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.

There are more, such as punch-outs (an organization changes providers, and
takes their address block with them), etc.

Do note that the exact details, and the benefits, will vary from case to
case, depending on the particulars; in some cases (e.g. the PI one), only
parts of the network which are running the location/identity separation
will benefit from reduced routing tables.

Which is, of course, not a bug, but a feature - it's an incentive to
those parts of the network to convert... :-)

	Noel

---

From: Michael Menth <[email-masked]>
Date: Wed, 25 Nov 2009 21:37:56 +0100

Hi Noel,

> generic concepts, i.e. 'identity' and 'location'.)
Many proposals actually deal with network attachment points (RLOCs) and 
names of endpoints (EIDs) which both serve to find the desired 
endpoint/interface. I call them global and local locators. They usually 
do not imply an identity that could easily move from one to another 
network or from one to another device. The fact that local locators are 
often called "identifiers" does not help to understand what proposals 
actually do.

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 26 Nov 2009 09:40:29 +0200

Noel

Thank you for the answer. So I conclude that that 

- for ISP internal and inter-domain scalability concerns we have the
evolutionary path of aggregating RIB/FIBs
- for stub networks we have identity/location separation or elimination

The two cases have different target scenarios, beneficiaries and
incentives for deployment.

Does it make sense to have one recommendation as we are essentially
dealing the problem of scalability in two different contexts. 

- Hannu 

>-----Original Message-----
>From: Noel Chiappa [mailto:[email-masked]] 
>Sent: Wednesday, November 25, 2009 21:09
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [rrg] moving towards recommendation: the current plan
>
>
>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. (Remember Wheeler's/Lampson's famous aphorisms about 
>problems in computer science being solved by another layer of 
>indirection, i.e. binding - separation of location and 
>identity gives us just such a layer of binding.)
>
>(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'.)
>
>
>Here are some examples of things which are causing extra 
>routing table entries to appear, which can be done without 
>those extra entries if there is a identity/location binding layer:
>
>- Injecting more-specifics into the external scope to cause 
>inbound traffic to take the optimal entry point: this can be 
>down with I/L separation by binding the addresses of different 
>parts of the internal scope to different entry routers (with 
>others listed as lower-priority, in case the prime router fails).
>
>- Multi-homing, which causes what are effectively PI addresses 
>(even if allocated from one provider's block) to be advertized 
>from routers connected to other providers: again, with I/L 
>separation, the different entry routers can be listed in that 
>block's binding, and only the location of the entry routers 
>(which can/should be given addresses from the block of the 
>provider to which they are attached) need be advertized - 
>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.
>
>There are more, such as punch-outs (an organization changes 
>providers, and takes their address block with them), etc.
>
>
>Do note that the exact details, and the benefits, will vary 
>from case to case, depending on the particulars; in some cases 
>(e.g. the PI one), only parts of the network which are running 
>the location/identity separation will benefit from reduced 
>routing tables.
>
>Which is, of course, not a bug, but a feature - it's an 
>incentive to those parts of the network to convert... :-)
>
>	Noel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Nov 2009 02:49:56 -0500

I am not following your conclusion, or how you got there from Noel's note.

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.
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.

FIB aggregation is a local trick.  It does nothing to help routing 
advertisements.  Also, while I will not sneeze at a 30% benefit (more 
runway is very useful), that clearly is not an architectural answer to 
the problems.
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.

Yours,
Joel M. Halpern

Flinck, Hannu (NSN - FI/Espoo) wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 26 Nov 2009 17:18:26 +0200

Joel,

Yes, you are right. I was too quick to make the conclusions based on who
gets the benefits. (I am not sure where the 30% reduction you mentioned
comes from, as I have seen higher numbers, but that's not an issue at
all.)

Also to my original question about the evolution (and the trajectories
in aggregation and separation) I found more in
draft-zhang-zhang-evolution-02.txt, where there are some "dotted lines"
for "converge towards separation". 

Best regards
Hannu

---

From: Christian Vogt <[email-masked]>
Date: Mon, 30 Nov 2009 00:03:44 -0500

On Nov 25, 2009, Noel Chiappa wrote:

> entries to appear, which can be done without those extra entries if
> there is a identity/location binding layer [...]

Very good points, Noel.  I note that, while your text is phrased in the
context of network-based identifier-locator separation, like in LISP,
similar arguments hold for a host-based separation. I recently explained
this in a different discussion thread:

http://www.ietf.org/mail-archive/web/rrg/current/msg05371.html

- Christian