Re: [rrg] Scalable Internet

On Wed, Nov 18, 2009 at 11:05 PM, Dae Young KIM <dykim at cnu.kr> wrote:
> 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.

that wasn't my point, my point was that walking into a room and
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.

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

in the simplest example 1 interface. I would hope that with many
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
LOCATOR (one locator per 'network' that you connect to, the locator is
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.

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

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.

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

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

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.

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

ASN isn't granular enough for traffic engineering concerns (or doesnt'
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.

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

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

Thank you.

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.