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: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] On
>Behalf Of ext Tony Li
>Sent: Monday, November 16, 2009 07:04
>To: Noel Chiappa
>Cc: rrg@irtf.org
>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?
>
>
>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.
>
>
>> 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?
>
>
>Please see our requirements draft.
>
>Tony
>
>_______________________________________________
>rrg mailing list
>rrg@irtf.org
>http://www.irtf.org/mailman/listinfo/rrg
>
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
