Typo:
The number space of IPv6 is already huge enough
should read
.... IPv6 .....
Regards,
DY
On Mon, Mar 29, 2010 at 5:25 PM, Dae Young KIM <[email protected]> wrote:
> 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 IPv6 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 <[email protected]> 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
>> [email protected]
>> http://www.irtf.org/mailman/listinfo/rrg
>>
>
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
