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. 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. -- Regards, DY http://cnu.kr/~dykim
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
