Subject: [rrg] Scalable Internet

From: Dae Young KIM <[email-masked]>
Date: Wed, 18 Nov 2009 13:36:48 +0900

Hi, Lixia,

I received some questions in private, and I think I was not specific enough,
though a short memo. I'm posting a revised text.

A power point material will be distributed within this week. A full text
proposal will be submitted by the due date, Dec. 15.

Can you count my short memo as one item of the list you're going to finish
within a few days?

-- 
Regards,

Dae Young
http://cnu.kr/~dykim

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 02:57:13 +0900

Hi, Christopher,

Please find my response interspersed.

On Wed, Nov 18, 2009 at 11:36 PM, Christopher Morrow <
[email-masked]> wrote:

> On Wed, Nov 18, 2009 at 6:02 AM, Dae Young KIM <[email-masked]> wrote:
> > On Wed, Nov 18, 2009 at 3:40 PM, Christopher Morrow
> > <[email-masked]> wrote:
> >>
> >> From your txt:
> >>
> >> A. Fundamentals:
> >>    o Skeletons:
> >>         o ID is global, Locator is local(private) to AS.
> >>
> >> isn't that backwards? ID == my local machine, 'locator' is my network
> >> attachment (or the network that I'm attached to).
> >>
> >> So the ID is required (and unique) only within my network, the
> >> 'locator' is unique globally.
> >>
> >> -chris
> >
> > There are two aspects to this.
> >
> >    1. Having locators local is a necessary first step to avoid the
> gateway
> > (aka IDR(Inter-domain Routing) router) table explosion. By not having to
> > manage global locators, gateways don't have to exchange (locator) network
> > prefixes and so keep their tables from growing indefinitely(or too
> > excessively, exponentially). Instead, they would advertise the AS
> numbers.
> > In fact, a AS number can be seen as an aggregated identifier of all the
> IDs
> > inside the AS's domain.
>
> In most of the past conversation: "ID" has meant the equivalent
> (loosely) of 'interface ip address' or 'interface attachment point'
>                                                "Locator" has meant
> the equivalent (loosely) of 'ASN'
>
> My reading of the initial quote did not match the above 2 items.
>

Actually, I'm new to this group, so don't have the collected knowledge of
past conversations. My sincere apology.

By ID here, I mean the ID of the host. This ID is to be used in Transport
connections with its peer. But it is not meant for routing.

Locator, by contrast, is for the interface, as you say, or
PoA(point-of-attachment).

I intentionally try not to use the term 'address' or 'IP address', since in
the current Internet, the IP address is used as both ID and Locator.

>
> >   2. IMHO, there's no compelling reason why the locators should be
> global,
> > in network architectural sense.
> >
> >         o All over the world, the street numbers would be sequenced from
> 1
> > to 100 or the like. They are local, but we don't have problems to
> reaching
> > someone we want.
>
> 'locator' in the sense of a mailing address (in the us) would be some
> combination of: ZipCode + town.
> 'identifier' in the sense of a mailing address (in the us) would be
> 'house-number' (or street number + apartment number).
>

No. 'house #' (street # + apt #) is still part of the locator to my
definition. Instead, your name on the envelope would be the ID in my
context.

> >         o How global is 'global'? What are we going to do about the
> > inter-planetary Internet? How about the spaceships on the moon or the
> Mars?
>
> I'm not sure geography matters here... network topology does.
>

Even in topology, how large is going to be your topology?

But, in fact, this is not the real point. Independently of the question of
the network size, there's no compelling network architectural reason for the
locator to be global in achieving the task of reaching (routing) to the
destination.

e2e routing can be done in a network of concatenated ASs each with local
locators.

> >          o Delivering packets, tagged with ID, to a regional authority in
> > charge of locating the objects within its region is enough to reach a
> > targeted receiver.
>
> 'tagged with locator' to the region, taking the identifier once it's
> inside the 'region' for final delivery to the end system.
>

No, the reverse. A packet in IDR(inter-domain routing) will only be tagged
with an ID of a target destination host. Once the packet arrives at an
ingress gateway (IDR router) into the AS the target host belongs to, the
packet will then be appended with a local locator of the AS ('region' in
your terminology). The local 'id-to-loc' (also serves as 'as-to-loc') mapper
provide the local locator to the target host.

> -Chris

I'm attaching the revised summary of my idea with the hope that it provides
a better picture of what I have in mind.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 18 Nov 2009 19:54:55 +0000

> past conversations. My sincere apology.

The mailing list archive's at:
http://www.ietf.org/mail-archive/web/rrg/current/maillist.html
2008 and before are at:
http://www.ops.ietf.org/lists/rrg/

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 05:54:27 +0900

> http://www.ops.ietf.org/lists/rrg/

Thank you.

> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Yet, I think I can still defend my definition of the term.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 18 Nov 2009 22:37:46 -0500

> Yet, I think I can still defend my definition of the term.

but redefining doesn't help the conversation that's been ongoing here
for .... 3+ yrs.

ID == host attachment point

Locator == network  (or loosely ASN in today's bgp4 routed world)

-chris

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 13:05:36 +0900

No, I'm not in the camp of LISP. I'm not in HIT, either. All I'm agreeing to
is just the idea that ID and Locator be separated.

And whatever the two group have been developing, if the definition is wrong,
then it's wrong. Not everything IETF has developed is right in
artchitectural sense. Some were fantastic, some were good, some were bad,
and some were even totally nonsense. We're engineers and we're not perfect.

LISP is not a bible. I don't feel any obligation to conform to their notion,
if something does not make sense to me.

Whatever I say seems to be non-sense to you or to the group, it's OK, you
can just reject it. No problem for me. But before that let me make my
arguments at least.

On Thu, Nov 19, 2009 at 12:37 PM, Christopher Morrow

> ID == host attachment point

OK. If you mean that there'd be only one host attachment point, it's OK. But
if you'd say, since a host can be attached through multiple interfaces,
there can be multiple IDs for a host, then I don't buy that. Then we mean
different things by the same acronym.

I think it was HIT which ever started this work of ID/Loc separation, and
the definition of ID for them is, if I'm not wrong, a unique identifier for
a host. And this ID is to be used in TCP connections throughout. This
conforms to my idea, too.

ID is host, and in normal operation, we'd expect there'd only one globally
unique ID for a host. This is the definition I buy.

> Locator == network  (or loosely ASN in today's bgp4 routed world)

Perhaps, then, you or the group or LISP means that the locator is a AS
number(ASN). Then again, this is against my definition, and LISP got it
wrong. When there arose discussions about ID/Loc separation even before HIT,
Locator was meant to an address that IP would use in routing as it uses IPv4
or IPv6 as routing locator. In their context, routing here means both intra-
and inter-domain. So, just as now, the locator (in fact IPv6 or IPv6
themselves in HIT) is used for routing, intra- and inter.

Now, here goes the difference from HIT idea again. I would use locator (IPv4
or IPv6 address) for intra-domain routing, but not for inter-domain routing.
For the Inter-domain routing, I would use ASN instead of the locators. In
this sense, my idea and LISP's meet. Both uses ASN for inter-domain routing.

So, perhaps, you can say my idea is mixture of HIT and LISP; like HIP for
intra-domain routing, like LISP for inter-domain routing.

I hope I made myself clearer.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 18 Nov 2009 23:37:05 -0500

> if something does not make sense to me.

that wasn't my point, my point was that walking into a room and
calling a square an octagon confuses things.

> different things by the same acronym.

in the simplest example 1 interface. I would hope that with many
interfaces there'd be only 1 'ID' and many combinations of ID and
LOCATOR (one locator per 'network' that you connect to, the locator is
the only thing relevant to 'routing' globally)

> conforms to my idea, too.

ok, I was merely simplifying for the conversation to 1 interface.

> number(ASN). Then again, this is against my definition, and LISP got it

ASN is a simplification, I'm not sure that 'ASN' is the right
construct, but in today's routing world it makes the conversation
easier to just say: "routing by ASN", surely that's not  the level of
granularity we need, but it gets things started.

> themselves in HIT) is used for routing, intra- and inter.

this probably depends on where the ID becomes significant... and for
host to host comms only the 'ID" matters (for the tcp/udp sessions as
we know them today).

> this sense, my idea and LISP's meet. Both uses ASN for inter-domain routing.

ASN isn't granular enough for traffic engineering concerns (or doesnt'
seem to be granular enough to me)

> I hope I made myself clearer.

a bit more. My reaction initially was to the seeming redefinition of
the terms... from the above it seems like things line up decently well
again (for me).

-chris

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 14:36:18 +0900

On Thu, Nov 19, 2009 at 1:37 PM, Christopher Morrow <[email-masked]
> wrote:

> calling a square an octagon confuses things.

OK. There I behaved myself improperly. (Not only this time, though.) I'm
then going to try to tune up the common shared understanding a little bit to
reach more solidified use of terminology.

> interfaces there'd be only 1 'ID'

OK, this is good. Keeping 1 ID (globally unique) for a host, independently
of the number of interfaces, is exactly what I want. Here, we agree.

and many combinations of ID and
> the only thing relevant to 'routing' globally)

What do you mean by combination. Do you mean, hopefully, the combinations
like

         (id1, loc1), (id1, loc2), (id1, loc3)

then it's ok to me. That's exactly what I mean. But if your combination
might be, for the same host,

        (id1, loc1), (id2, loc2), (id3, loc3)

then that's not the way I chose in my architecture.

> granularity we need, but it gets things started.

What do you mean by routing? "inter-domain routing by ASN"? or "intra-domain
routing by ASN"? Or both?

In my proposal, only inter-domain routing uses ASN. Intra-domain routing
uses locator(in fact, IP address, as usual).

> host to host comms only the 'ID" matters (for the tcp/udp sessions as

For long in the IETF community, or at least in the context of HIT, 'ID'
means the identifier for host. There's no use of ID or identifier for other
purposes.

Or, if you don't agree to this, then let's be more specific to say what I
mean is 'host ID'. There's be a unique host ID for a host.

> seem to be granular enough to me)

On a specific link between a gateway of an AS and another gateway of a
neighboring AS, there's no branch out, and so there's no finer granularity
than having the total traffic volume over this link a given value.

Finer traffic control onto individual flows on that link is a task belonging
to inside of an AS. Flows into, from inside, the egress gateway should
controlled before the aggregated traffic is pumped out of the other end of
the egress router traveling to the gateway of the neigboring AS.

So, once on the link between the gateways belonging to different ASs, there
is no need for finer granularity of traffic conrol than AS.

Thank you.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 19 Nov 2009 01:39:02 -0500

On Thu, Nov 19, 2009 at 12:36 AM, Dae Young KIM <[email-masked]> wrote:
> On Thu, Nov 19, 2009 at 1:37 PM, Christopher Morrow

actually I think the ID doesn't have to be globally unique. It's
convenient if it is (today), but it need not be globally unique.

>          (id1, loc1), (id1, loc2), (id1, loc3)

yes, same ID, many LOCATORs (networks to which the ID attaches)

> then that's not the way I chose in my architecture.

There CAN BE more than one ID, but I don't see a use in most cases to do that.

> routing by ASN"? Or both?

I can envision some networks which are large enough that there may be
separate locators used to map to different portions (or
entrances/exits) to that network. So, many LOCATORS for a single ASN.

The 'ASN is a simplification' really means 'simplification'... it's
very easy to image: "Route to joe at AS701, route to jim @ as15169"
... it's probably harder for many people to image: "Route to IDX at
LOCATOR-Y"

> uses locator(in fact, IP address, as usual).

I think that's fine. 'interdomain' and 'intradomain' are going to mean
something different 'soon' (or could mean something different soon),
though this is less important I think.

> means the identifier for host. There's no use of ID or identifier for other

ok

> mean is 'host ID'. There's be a unique host ID for a host.

sure

> than having the total traffic volume over this link a given value.

there are a vast number of AS's that interconnect in more than 1
interface, in more than 1 location... being able to determine that
this portion of AS15169 is on interface 3 and 4 but not 5, while that
portion of AS15169 is on 5 and not 4 or 3... is important.

> is no need for finer granularity of traffic conrol than AS.

there is need inside the ASN's to find the right set of links to carry
the traffic in question. It's more complex when that path is not a
direct one... transit {3356 701 6461} from 15169 to 2914.

-Chris

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 19 Nov 2009 21:19:04 +0900

On Thu, Nov 19, 2009 at 3:39 PM, Christopher Morrow <[email-masked]

> convenient if it is (today), but it need not be globally unique.

Yes, you're right. In fact, I was going to propose that way, but I was not
sure whether the group already has got this notion. Many people out there
believe BOTH id AND locator should be global. In fact, there's no compelling
architectural reason why they have to be globally unique.

I'd be quite happy to change revise my idea in this respect, if we'd be sure
the group will understand the reason for and accept the idea.

> There CAN BE more than one ID, but I don't see a use in most cases to do

Right.

Again, in fact, there can be multiple names for a host; alias. But, this is
not a necessity, and should rather be treated as a degenerate case in order
to make our discussion concise and clear. So, for the purpose of clearer
communication of opinion and ideas, I'd prefer to say that there's on ID for
a host.

> entrances/exits) to that network. So, many LOCATORS for a single ASN.

Indeed. But, I'd describe this situation like this. A large admin domain can
have multiple AS's inside; (this is also true of the current Internet).
Although the whole (large) domain (network) would be admin'ed by a single
authority, each AS inside would use separate set of locators.

Is this OK to you? Then, we mean the same thing.

> ... it's probably harder for many people to image: "Route to IDX at

Yes. We mean nearly the same thing. Only that, for me, 'joe' or 'jim' is in
the header of TCP whereas 'AS701' or '@as15169' is in the IP header. So, in
relaying between AS's, availability of only the AS # to IP(relayer) is
enough for this inter-domain operation. It's only when the packet arrives at
the gateway into the intended AS, the packet needs further information of
the (local) locator to the host 'joe' or 'jim'. These can be retrieved (if
not cached) from the LocS(id-to-locator mapper) inside the AS. This is why I
say

     o AS is used in the inter-domain routing whereas
     o locator is used in the intra-domain routing.

> though this is less important I think.

Yes, also in my picture (in head), ASs can recurs inward and outward (or
upward and downward), so that this distinction by 'intra' and 'inter' may
not be right wording. This, however, is to mean whether the routing is a
tier above or below... or something like that.

 >direct one... transit {3356 701 6461} from 15169 to 2914.

Aha. So, that's why you feel exposure of ID even in inder-domain routing is
necessary.

Let me try to revise my two scenarios like this:

(outgoing step1: still inside) before forwarding a packet (or flow, which is
a more convenient granularity here) to one of multiple egress gateways all
pointing to the same external AS, a traffic engineering configurer would be
consulted to which egress gateway the flow should be forwarded. ...

(outgoing step2; exiting the gateway) Assume my gateway has links to more
than one ingress gateways of my neighbor. In further segmenting the flows
assigned to my gateway, I'd also consult ...

No... I think it doesn't work without exposure of the ID to gateways. I
think I break here. Well..., painful.

This then sends me back to the first issue of ID we talked about. I might
then, from outset, declare IDs in my architecture is also local; comfortably
manageable quantity of manageable size.

OK. I might have to redraw the architecture and scenarios and let ID be
visible in inter-AS routing. I'll have to see whether this still ensures me
the scalability of this routing; whether the routing table doesn't explode.
I hope I succeed. Will get back soon.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 20 Nov 2009 07:19:42 +0900

On Thu, Nov 19, 2009 at 9:19 PM, Dae Young KIM <[email-masked]> wrote:

> (outgoing step1: still inside) before forwarding a packet (or flow, which
> is a more convenient granularity here) to one of multiple egress gateways
> all pointing to the same external AS, a traffic engineering configurer would
> be consulted to which egress gateway the flow should be forwarded. ...
>

Now I had another closer look at my own arch overview, being attached, and I
think I can still stick to my model(global id, not exposed in IDR).

Please have a look at the attached picture. AS6 is seen through two
gateways, G1 and G2. The current case shown is to take G2 as a preferred
exit.

Assume we'd like to divide the 'red' flow and send part of the flow to G1
and some other part to G2. A traffic manager (not shown here) would interact
with LocS to let it return two locators each pointing to G1 and G2, thus
enabling split flows delivered accordingly. So, outgoing step 1 above works
without a problem.

Now about outgoing step 2. What I was going to take as a case is where there
are multiple links from an egress gateway to the next hop AS. For example,
AS2 and AS3 in the picture collapses to one(say A23), in which case Ga has
two links to AS23. So, there's a possibility of injecting flows from Ga into
the same AS23 through two gateways.

But here, I'd like to impose a restriction. In the scenario just described,
Ga is not allowed to send over two links to the same AS, i.e., AS23. Then, I
still don't have to expose ID on these links, conforming to my original
architecture.

Would this restriction be too artificial? How is current BGP running? Is it
allowed to inject flows from a gateway through multiple entries to a
neighboring AS? I'd like to know. (Apology. I'm, in fact, not a proper
expert in routing.)

-- 
Regards,

DY
http://cnu.kr/~dykim <http://cnu.kr/%7Edykim>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 20 Nov 2009 15:29:22 -0500

Actually, I do not think that most folks using the terms are using ID 
for "host attachment point."
I believe the primary semantic for ID that most people are using is 
"Identifier for communication point with the property that the 
identifier does not change if the topological placement of the 
communicating entity changes."

There is outstanding discussion as to whether this identifier is, or 
must be, or may be, the network attachment point, the network stack, the 
transport stack, or the application.
I tend to be in the family that wants to name the network/transport 
stack.  I tend to treat the cases whee the network attachment point 
needs to be named (for example, for monitoring purposes) as a special 
case which can be treated as a stack associated with that entity.
But I will readily agree that this is not settled.

Yours,
Joel

Christopher Morrow wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 21 Nov 2009 10:14:53 +0900

> seem to be granular enough to me)
I did some more exercise and roughly figured out how to defend my idea of AS
IDR with respect to the granularity for traffic engineering.

In that course, I even took another bold step to also keep ID local, not
just LOC.

Please find my new exercise being attached, and your harsh comments are more
than welcome.

-- 
Regards,

DY
http://cnu.kr/~dykim