Subject: [rrg] RRG mission

From: Toni Stoev <[email-masked]>
Date: Sun, 28 Mar 2010 21:56:49 +0300

I hope this is the end of personal feud here.
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.

---

From: Robin Whittle <[email-masked]>
Date: Mon, 29 Mar 2010 11:09:50 +1100

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

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

> 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

---

From: Toni Stoev <[email-masked]>
Date: Mon, 29 Mar 2010 10:46:18 +0300

> contribution to the RRG and would stimulate further constructive

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

---

From: Dae Young KIM <[email-masked]>
Date: Mon, 29 Mar 2010 17:35:33 +0900

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 <[email-masked]> wrote:
>>                  > If you want to tell the world what to do with the
>>                  > IP routing system, act now.
>>
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Dae Young KIM <[email-masked]>
Date: Mon, 29 Mar 2010 18:02:57 +0900

Additional implications:

   o Node (IP) address changes at mobility. (It is not fixed, globally
unique...)

   o Intra-domain routing is done based on node addresses, not on PoA
(interface) addresses

   o There's nothing like PoA (interface) address in the scenario.
Gone. This is no problem, since the same information is with the
sub-layer node address, e.g., MAC address.

Regards,
DY

---

From: Toni Stoev <[email-masked]>
Date: Tue, 30 Mar 2010 05:54:47 +0300

Thank you Dae Young for the warm welcome.

>    o Node (IP) address changes at mobility. (It is not fixed, globally

Node locator changes at mobility. It is not fixed, but is routing domain unique.

> > Question: Is LINP based on the ideas you describe? Hope so. Otherwise...

Honestly, I don't know.

> >        o Mobility is just dynamic multi-homing, perhaps a bit too fast.

:-)

> > close to my idea or to your idea? I might like to support such a

Most of my ideas imply variable length number sequences, which are realized through variable length number writing:
Binary Indicators-Termination Sequence http://bit-sequence.fdns.net/content.en.html

There is an efficient way of elaborating documents – the wiki.
I am going to make use of this one: http://trac.tools.ietf.org/group/irtf/trac/wiki

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 30 Mar 2010 22:03:53 +0900

Regards,
DY

> Node locator changes at mobility. It is not fixed, but is routing domain unique.

Yes. I meant, 'not globally unique.
> I am going to make use of this one: http://trac.tools.ietf.org/group/irtf/trac/wiki

Great.

---

From: Dae Young KIM <[email-masked]>
Date: Mon, 29 Mar 2010 17:25:17 +0900

Toni,

In this way,

don't even need IPv6. The number space of IPv6 is already huge enough

Regards,
DY

---

From: Dae Young KIM <[email-masked]>
Date: Mon, 29 Mar 2010 17:27:42 +0900

Typo:

      The number space of IPv6 is already huge enough

should read

      .... IPv6 .....

Regards,
DY

---

From: Dae Young KIM <[email-masked]>
Date: Mon, 29 Mar 2010 17:29:42 +0900

Repeated typo:

   .... IPv4 ....

(Perhaps, I like IPv6... :-))

Regards,
DY