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

From: [email-masked] (Noel Chiappa)
Date: Sun, 15 Nov 2009 21:28:59 -0500 (EST)

> From: Lixia Zhang <[email-masked]>

    > RRG is due for a recommendation to IETF on scalable routing solution
    > ...
    > RRG will have focused discussion on contrasting, comparing and
    > critiques of all the candidate proposals.

Apologies if this question is something that's been covered already, but is
it the intent to recommend a single thing, or would the recommendation cover
a list of things which fit together to form a solution?

E.g. an overall solution might include a number of things, one of which is
separation of location and identity (and perhaps a specific proposal to
implement that), and other(s) of which might be a list of changes to the
routing itself.

If so, would a recommendation to do separation of location and identity be
something that this RRG would feel is 'in scope' for it, or is that outside
our area? (Saying 'we cannot see any solution to routing scaling _without_
separation of location and identity' is probably within scope, and amounts to
the same thing, so I guess maybe it is in scope.)

Finally, is pure scaling the only requirement for the future that the RRG is
supposed to provide for, or are there other things the routing system should
be able to do in the future?

	Noel

---

From: Tony Li <[email-masked]>
Date: Sun, 15 Nov 2009 21:03:42 -0800

> a list of things which fit together to form a solution?

The point is to propose a new routing architecture, as per the charter. 
    If that comes in pieces (e.g., a mapping function, and a translation 
function), that's acceptable.  However, multiple instances of a single 
component (e.g., two mapping functions) are not reasonable.  Please make 
your own choices about what you're proposing.

> the same thing, so I guess maybe it is in scope.)

Yes, making architectural changes outside of the routing protocols is 
certainly in scope.  BTW, we took a poll last Friday and had a nearly 
unanimous agreement that separation IS required to solve this problem.

> be able to do in the future?

Please see our requirements draft.

Tony

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 17 Nov 2009 09:27:42 +0200

I think that targeting for a single recommended solution would not be
practical. See for instance what has happened during the years in
IPv6/IPv4 transition. There is a set of tools for a number of deployment
scenarios. These tools differ quite a lot on their assumptions. 

It looks to me that locator identifier separation is similar to the IPv6
- IPv4 transition in many ways. It touches address structures, contains
translation and tunneling aspects etc. 

Based on this it seems that in order to progress the routing evolution
the recommendation should distill the fundamentals and their
characteristics, instead of recommending a solution. Further based on
the IPv6/IPv4 transition it is very likely that because of different
deployment cases, there needs to be different (multiple?) steps towards
the complete solution. There are different starting points as well as
different timing needs that are causing this. In order to accommodate
the diversity of deployment scenarios and schedules the recommendation
should focus in my opinion into the fundamentals to establish a basis
for further work, rather than trying to converge into a single solution
that hardly fits into most of the use cases. The recommendation should
create the basis for a modular and evolvable routing architecture.

Best regards
Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Tony Li
>Sent: Monday, November 16, 2009 07:04
>To: Noel Chiappa
>Cc: [email-masked]
>Subject: Re: [rrg] moving towards recommendation: the current plan
>
>Noel Chiappa wrote:
>
>> Apologies if this question is something that's been covered already, 
>> but is it the intent to recommend a single thing, or would the 
>> recommendation cover a list of things which fit together to 
>form a solution?
>
>
>    If that comes in pieces (e.g., a mapping function, and a 
>translation function), that's acceptable.  However, multiple 
>instances of a single component (e.g., two mapping functions) 
>are not reasonable.  Please make your own choices about what 
>you're proposing.
>
>
>> If so, would a recommendation to do separation of location and 
>> identity be something that this RRG would feel is 'in scope' for it, 
>> or is that outside our area? (Saying 'we cannot see any solution to 
>> routing scaling _without_ separation of location and identity' is 
>> probably within scope, and amounts to the same thing, so I 
>guess maybe 
>> it is in scope.)
>
>
>Yes, making architectural changes outside of the routing 
>protocols is certainly in scope.  BTW, we took a poll last 
>Friday and had a nearly unanimous agreement that separation IS 
>required to solve this problem.
>
>
>> Finally, is pure scaling the only requirement for the future 
>that the 
>> RRG is supposed to provide for, or are there other things 
>the routing 
>> system should be able to do in the future?
>
>
>_______________________________________________
>rrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Nov 2009 16:12:18 +0800

> scenarios. These tools differ quite a lot on their assumptions. 

This looks right.  I like Lixia's proposal for "evolution" and a
toolkit, although not necessarily using the tools she recommends.

> translation and tunneling aspects etc. 

I'm going to get on the soapbox about this one more time: The point of
locator/identifier separation (LIS) is not necessarily to create new
identifiers.  It's truly separation of Identification from Location --
to stop identification functions from depending on location-dependent
information (like addresses).  Therefore LIS does not _necessarily_
touch address structures, does not need to imply translation or tunnels,
etc.  However, to the extent that you cannot get existing identification
functions (at various layers) free of their addiction to
location-dependent information, routing+addressing may be the likely
place to make up for their shortcomings, and to do that you might do all
of these things.  But LIS does not itself does not require changes to
addresses etc.

Back to the main theme now.

Scott