On Thu, Nov 19, 2009 at 12:36 AM, Dae Young KIM <[email protected]> wrote:
> On Thu, Nov 19, 2009 at 1:37 PM, Christopher Morrow
> <[email protected]> wrote:
>>
>> On Wed, Nov 18, 2009 at 11:05 PM, Dae Young KIM <[email protected]> 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.
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.
>
>> 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)
yes, same ID, many LOCATORs (networks to which the ID attaches)
> 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.
There CAN BE more than one ID, but I don't see a use in most cases to do that.
>>> 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?
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"
> In my proposal, only inter-domain routing uses ASN. Intra-domain routing
> 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.
>>
>> 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.
>
ok
> 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.
sure
>>
>> > 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.
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.
> 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.
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
>>
>> > 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.
>
> --
> Regards,
>
> DY
> http://cnu.kr/~dykim
>
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
