Subject: Re: [rrg] Another Routing RG Straw Poll

From: [email-masked] (Noel Chiappa)
Date: Sat, 22 May 2010 13:06:10 -0400 (EDT)

> From: Dae Young KIM <[email-masked]>

    > the role of PoA is already served by MAC address, and not has to be
    > duplicated by extra 'Locator'.

i) Not all networks have a MAC (although most do, now).

ii) A MAC serves to globally _identify_ an interface, but it is not enough to
_locate_ it (i.e. to be useful to the path selection). It will be necessary
to add some extra information, such as a structured name of the network the
interface is connected to, to make it an interface name which the path
selection (routing) can use. After all, if you do not have that extra
information, you basically have a world-wide bridged network.

Remember, my question was in the context of a node which has _two_
interfaces, to widely separated (in network connectivity terms) networks,
such as i) a particular wireless LAN, and ii) a 3G cellular network.

    > mobility is inherently supported by routers without resorting to extra
    > mapping (ID>Loc) or agent(HA/FA) infrastructure.

Only within an AS. What happens if the node leaves the AS (perhaps to a
different wireless LAN)?

	Noel

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 23 May 2010 02:43:22 +0900

On Sun, May 23, 2010 at 2:06 AM, Noel Chiappa <[email-masked]> wrote:
>    > From: Dae Young KIM <[email-masked]>
>
>    > the role of PoA is already served by MAC address, and not has to be
>    > duplicated by extra 'Locator'.
>

Not necessarily. I think I can build a sound network topology only
with node addresses. CLNP, for example, didn't need interface address
to do routing.

> such as i) a particular wireless LAN, and ii) a 3G cellular network.

Why should it be a problem in my picture?:

  - At inter-net level, my node will have two links each pointing to a
remote router at the other surface of either LAN or 3G.

  - LAN will identify one of the interface with its MAC address while
3G will do the other with its L2 address(whatever it is).

>
>    > mobility is inherently supported by routers without resorting to extra
>    > mapping (ID>Loc) or agent(HA/FA) infrastructure.
>

Moving across LANs within an AS won't affect its fast mobility.

There'll surely be a problem in fast mobility when a node leaves an AS
for another AS:

    o In its most primitive fashion, the TCP connection would break.
You have to reconnect.

    o A fast inter-AS context-switching mechanism might be devised.

    o DNS should be updated with a new mapping, name > (addr, AS-new).
This, of course, is a challenge; DNS synchronization is slow. How to
work around this?

I have yet to work on these inter-AS mobility issues. Hope I won't totally fail.

-- 

Regards,
DY

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 23 May 2010 00:54:44 -0400

Note that although CLNP use Node Identifiers, these were coupled to 
subnet locators.  That is, the NSAP specifically identified the subnet 
to reach the host on.  Further, out expectation was that a preamble to 
the NSAP would be the service provider providing connectivity.  SO that 
the NSAP was a topologically sensitive address, with a NODE identifier 
as the last portion.
(Yes, there are parallels to some of the other ideas this research group 
has discussed.  We did not take that work anywhere near there at the time.)

Yours,
Joel

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 23 May 2010 15:11:45 +0900

Resemblance to CLNP ends with that my one uses node address;

   - Node addresses are local with me while it is global with CNLP.
   - I don't carry subnet locators.

In my model, packets are not routed on the subnet locator (which is missing
in my model). Rather,

   - Each subnet router keeps track of the membership of nodes inside its
subnet.

   - Whenever there's differential in the membership, by either a new
incoming node or a leaving node, this change of membership would be
broadcast to other subnet routers in the same domain(AS).

    - Assuming the an LS routing is used inside a domain, such differential
can also be distributed as an addendum to normal LS update packets.

    - So, each router will know where any node should reside in a subnet
managed by which router.

    - Since the routing is still LS, each router keeps knowledge of the
whole network topology so that shortest paths can be determined, which will
then indicate what will be the next hop router for a destination node from
the current router.

    - All this can be done without padding locators (or addr of subnet
router) to each packets. Packets carry only node address and AS numbers
instead, the latter not being used within an AS but only to be used for IDR.

    - The whole intra-domain routing operation might look similar to bridge
operations. Not totally, however. Just similar.

    - The penalty is that we deal with flat node addresses.

    - The gain is that mobility is provided directly by routers as part of
inherent operations of routing. No extra infrastructure like HA / FA or
ID/Loc mapping servers. This way, faster mobility can be provided since it
is done directly by routers.

     - The whole structure is much friendlier to mobility. Mobility is an
inherent feature, not as added/patched-on function.

The whole point is:

    - In contrast to common belief that you need ID and Locator separately
to provide seamless mobility,

    - the same can be done only with an identifier of a node (now I call
node address), without extra bothering about locators.

This description is more from the mobility perspective, but also renders
consequences of routing in general:

    - Address is local, name is global.
    - IDR operates only on AS numbers or Domain addresses. (Node) addresses
are used only in inter-domain routing.
    - In a sense, IDR is quite symmetrical to intra-domain routing, with
migrating(multi-homing) domains seen as network nodes.
    - So, any routing can be used for IDR. People might still prefer policy
routing and hence BGP4-modified.
    - Size of the routing table is limited by the AS# space. Too big? Then,
split in multi-tiers.
    - No Internet governance since address are local. (Although that for AS
will still in place. But much less political.)

On Sun, May 23, 2010 at 1:54 PM, Joel M. Halpern <[email-masked]>wrote:

> Note that although CLNP use Node Identifiers, these were coupled to subnet
> locators.  That is, the NSAP specifically identified the subnet to reach the
> host on.  Further, out expectation was that a preamble to the NSAP would be
> the service provider providing connectivity.  SO that the NSAP was a
> topologically sensitive address, with a NODE identifier as the last portion.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sun, 23 May 2010 15:15:50 +0900

Typo:

 >> - ..... only in intra-domain routing.

-- 
DY

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 23 May 2010 10:53:29 -0400

You are treating the AS Number as your locator.
As has been discussed on this list, that has the wrong granularity for 
operators needs.

More importantly, you are requiring that each AS keep of full list of 
all hosts in all customers.  Not only do enterprises not want to provide 
this ifnormation to their operators, but that is potentially a VERY 
large amount of information.  Which operators do not want to have to 
distribute across the entire AS.  (Even residential operators would not 
want to have to distribute the IDs of every host at every home across 
their entire AS.)

Yours,
Joel

Dae Young KIM wrote:
...
> instead, the latter not being used within an AS but only to be used for IDR.
....

---

From: Tony Li <[email-masked]>
Date: Sun, 23 May 2010 12:08:10 -0700

>     - The penalty is that we deal with flat node addresses.

The other penalty is that inter-domain routing now is running on a flat
4-byte number. Routing now needs to scale to 2^32 items and scales linearly
with the number of organizations in the network.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Mon, 24 May 2010 09:37:57 +0900

Joel,

You're misunderstanding my description. I admit my slides are short of wordings.

  - Node addresses are local to each AS, so each AS manages only their
own member list. ASs don't keep full list of all hosts in all
customers.

  - As soon as a packets exits an AS to the inter-domain region, the
node address loses its meaning(or is not relevant), and the IDR
routers would only look at the dst AS# imbedded in the packet to
execute IDR.

On Sun, May 23, 2010 at 11:53 PM, Joel M. Halpern <[email-masked]> wrote:
> More importantly, you are requiring that each AS keep of full list of all
> hosts in all customers.  Not only do enterprises not want to provide this
> ifnormation to their operators, but that is potentially a VERY large amount
> of information.  Which operators do not want to have to distribute across
> the entire AS.  (Even residential operators would not want to have to
> distribute the IDs of every host at every home across their entire AS.)
>
> Yours,
> Joel
>
> Dae Young KIM wrote:
> ...
>>

-- 

Regards,
DY

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 23 May 2010 21:48:17 -0400

I understood you were using Node Address only within the AS.
(We won't explore the question of how you put the destination AS number 
and destination address into the packet, as that is minor compared to 
the other issues.)

You ddi not comment on the fact that AS granularity is just the wrong 
granluarity.

You also seem to have misunderstood my large comment.  I will presume 
that the AS is to include the last serving ISP and all of their customers.
If instead you intend that every site have its own AS, then Tony's 
comment about the large number of AS numbers you get is, if anything, 
understated.
So, assuming that the AS includes its end-site customers, then in order 
for the AS to route on node-IDs, which are not derived topologically 
from points of connectivity to the topology, that implies that the AS as 
a whole is flat-routing on the ID space of ALL the nodes in ALL the 
sites served by that AS.  Sorry, that simply will not work.

Yours,
Joel M. Halpern

---

From: Dae Young KIM <[email-masked]>
Date: Mon, 24 May 2010 11:46:42 +0900

On Mon, May 24, 2010 at 10:48 AM, Joel M. Halpern <[email-masked]> wrote:
> (We won't explore the question of how you put the destination AS number and
> destination address into the packet, as that is minor compared to the other
> issues.)

The DST address will be put in the usual DST IP address field. Where
to put the AS numbers (both SRC and DST) will be an implementation
issue.

I'd prefer to put in the IP option field, but there were opinion that
most current routers simply ignore any IP options.

Or put it in the net mask field

> You ddi not comment on the fact that AS granularity is just the wrong

Wrong in what sense? In regards to traffic engineering(TE)?

In the IDR level, although only AS# will be used for routing, the
whole packet header is still visible.

So, if you'd want to apply any TE at as deep as node address, you can
still do that since

   (src addr, src as; dst add, dst as)

are all visible to inter-domain routers.

>
> You also seem to have misunderstood my large comment.  I will presume that
> the AS is to include the last serving ISP and all of their customers.

Here, I might not be precise what I mean by AS. Should I call it a domain:

   o AS is an entity which will have its independent authority to
assign addresses to the nodes inside the AS.

   o Also, each AS will choose whatever intra-domain routing as it
serves its purpose.

> If instead you intend that every site have its own AS, then Tony's comment
> about the large number of AS numbers you get is, if anything, understated.

Perhaps.

But, is the size of the table the real threat?

   - With 16-bit AS, the table entry will be < 2**16(16K)
   - With 32-bit AS, it will be < 2**32(64M)

Assuming 1KB for each entry vector, the memory will be

   - 16MB or 64GB

I'd assume these are affordable sizes for IDR routers which should
usually be heavy machines.

The remaining problem is to look-up speed, for which there's be a
whole lot of tricks.

The real problem, from my perspective, might be that we now use
intra-domain node addresses in finding paths in inter-domains. You
scan the table at the granularity of node address. Although you're
using net prefixes, they are derived from node addresses.

I'd say using address which belongs to the inter-domain, that is AS or
domain address, should be the granularity in IDR.

> So, assuming that the AS includes its end-site customers, then in order for
> the AS to route on node-IDs, which are not derived topologically from points
> of connectivity to the topology, that implies that the AS as a whole is
> flat-routing on the ID space of ALL the nodes in ALL the sites served by
> that AS.  Sorry, that simply will not work.

Here, we're talking about intra-domain routing, aren't we?

If you'd mean 'operate' by 'work', I'd say it should work, why not.

If you'd mean 'the address space to be handled by an AS is too big',
then I'd partly agree.

But, for example, even for a 'conventional' A-class AS, the node
address space will be limited by 2**24. For most AS's, a size of 2**16
or a few multiples of it might suffice. The burden on the intra-domain
routers is to keep managing table of this size.

So, TOO big, you mean?

-- 
DY