Toni,
This is one of the descriptions I'd like the most in this mailing
list. Wonderful.
Question: Is LINP based on the ideas you describe? Hope so. Otherwise...
I might have the same views as yours, but the parts I like the most include:
- Name the node, not the interface.
- Do inter-domain routing by use of domain IDs.
To go a little bit further, a picture I have would be:
- Use FQDN as the name for your content/application/node...
- Use IP address to name to nodes; Redefine the meaning of the IP
address, it names the node, not the interface.
- In the intra-domain routing, this nod (IP) address would be used
just like now with OSPF.
- Use domain IDs in inter-domain routing.
In this way,
- except redefinition of the meaning of IP address,
- nearly nothing changes;
o (Possibly extended) DNS can be used as before.
o Existing hosts may not be changed, keeping their IPvX
addresses, perhaps only one is enough
o OSPF works just the same
o Basic operations of BGP can be kept with new formatting
based on domain IDs. If current ASN infra is not appropriate, then
maybe design new numbering scheme for domains.
o Multi-homing will be inherent, now that nodes are named,
not the interface.
o Mobility is just dynamic multi-homing, perhaps a bit too fast.
- one important implication is:
o Now that inter-domain routing is done by use of domain IDs,
host IP addresses need not be globally unique. They can be local. We
don't even need IPv6. The number space of IPv4 is already huge enough
for any local domains. Of course, there might be additional benefits
for using IPv6. They can choose to use IPv6, no problem. They are
local anyway.
I've been away from this ML for long, and do we have any proposals
close to my idea or to your idea? I might like to support such a
proposal.
Regards,
DY
On Mon, Mar 29, 2010 at 4:46 PM, Toni Stoev <i...@tonistoev.info> wrote:
>> Please write something along these lines - I think it would be a good
>> contribution to the RRG and would stimulate further constructive
>> discussions.
>>
>> - Robin
>
> I came to this group with a clear vision on network architecture.
> What I liked here were the well defined design goals. I agree more input is
> relevant.
> Things that I envision: [Slow down for reading.]
> Naming node, not interface, with locator, identifier.
> Strict topology following by locator, that is, every next hop towards a node
> within a routing domain to be inscribed. Next hop inscriptions – neighbor
> identifiers. This implies variable locator size.
> Intra-domain routing then becoming piece of cake: locator longest prefix
> match. This implies a starting node in every routing domain.
> Binding of routing domain identifier with locator. In a role-based
> architecture: locator role implies routing domain ID role (roles realized as
> header options).
> Then, inter-domain routing based not on intra-domain locator( prefixe)s, but
> on domain identifiers only. Routing domain IDs then forming paths (No
> reinventing the wheel.).
> Node identification system: bidirectional numerical DNS-like system.
> Bidirectional means a node identified knows locator of its parent and the
> parent knows locator of its child. These acquaintance IDs forming fully
> qualified node number sequence – the node identifier.
> I enjoy this part, quoting other people: Node mobility is dynamic
> multihoming. Having node identification system, a node roams with locators
> coming and going, and is discoverable through its identifier.
>
> Cheer everyone
>
> On 29.03.2010 at 03:09:50 Robin Whittle sent:
>> Short version: Tony Stoev wrote, in part:
>>
>> > If you want to tell the world what to do with the
>> > IP routing system, act now.
>>
>> I agree - and suggest he and other people write some
>> Recommendation text they would most like everyone to
>> agree with.
>>
>>
>>
>> Hi Tony,
>>
>> You wrote:
>>
>> > I hope this is the end of personal feud here.
>>
>> I think RRG participants are unlikely to be happy with a
>> Recommendation which was made by the co-chairs alone, without any
>> attempt at seeking consensus - especially if the final document
>> represents the Recommendation as arising from the group itself.
>> Their intention to write the Recommendation themselves only emerged
>> when I asked them to clarify their plans on 7th March.
>>
>> Also, some people - me at least - think that the co-chairs could have
>> done a much better job of supporting discussions in the last three
>> years. Discussion of "proposals" was generally banned or discouraged
>> - but they did not do much to suggest why this was being done or to
>> lead whatever kind of "architectural" discussion they wanted. Except
>> for two very early drafts, (draft-irtf-rrg-design-goals-01) they did
>> not seriously pursue the creation of a "list of prioritized design
>> goals" as required by the Charter.
>>
>> Furthermore, as I wrote a few days ago (msg06373) the co-chairs seem
>> to seriously misunderstand Ivip and at least some of the other
>> proposals.
>>
>> Still, even if there is no Recommendation - or no Recommendation
>> which arises from the participants - I think some important work has
>> been done, with several proposals being designed, refined and
>> documented in a manner which is of lasting value.
>>
>>
>> > This working group has a charter to produce recommendation.
>> > If you want to tell the world what to do with the IP routing system, act
>> > now.
>>
>> I agree. I did so with the Ivip proposal, by critiquing all the
>> other proposals, and by writing some text of what I consider to be an
>> ideal Recommendation:
>>
>> http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
>>
>> The only think I would change about that is my assessment of
>> IRON-RANGER, which has been significantly redesigned in the last
>> week. I think it is an interesting CES architecture which probably
>> could be made to scale well.
>>
>> You have been participating in the mailing list for nearly a year,
>> but looking through some of your messages, I don't have a clear idea
>> of what you think should be done to solve the routing scaling problem.
>>
>> I suggest you and others write to the list with your own preferred
>> text for what you suggest would be a good Recommendation.
>>
>> Since there is no agreed set of goals, I suggest that you begin with
>> your goals and non-goals and your arguments for these. For instance,
>> are you keen for an architectural upgrade to include new support for
>> Mobility? Mobility is part of the problem the RRG is supposed to be
>> tackling - but it has received little attention, since most work has
>> been focused on portability, multihoming and TE for non-mobile networks.
>>
>> Then I suggest you refer to each of the proposals, giving reasons why
>> you favour them or not. Perhaps you wholly support one of them, or
>> have qualified support for several of them. Perhaps you support an
>> alternative architecture which is different from those in the proposals.
>>
>> I don't think it is good enough to simply discuss a preferred
>> architecture. I think that for any Recommendation (from an
>> individual or from the RRG as a group) to have credibility, it must
>> provide detailed reasons for rejecting all the other proposals.
>> Without this - and without those arguments being clear and based on a
>> good understanding of all the proposals - a Recommendation for any
>> one architecture would be incomplete and would not contribute to
>> constructive discussion.
>>
>>
>> Please write something along these lines - I think it would be a good
>> contribution to the RRG and would stimulate further constructive
>> discussions.
>>
>> - Robin
>>
>>
>
>
> _______________________________________________
> 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
