On Fri, May 28, 2010 at 12:33 AM, Fred Baker <[email protected]> wrote: > There can be at the transport or application layers, in two forms. In both > cases, the issue is that a network layer address is meaningful at the network > layer and not really meaningful above it, but we have collectively not done > well in remembering that. For a good rant on the topic, I would suggest > reading the works of Saltzer such as > > http://www.ietf.org/rfc/rfc1498.txt > 1498 On the Naming and Binding of Network Destinations. J. Saltzer. > August 1993. (Format: TXT=24698 bytes) (Status: INFORMATIONAL) > > or listening to John Day. > > At the Transport Layer, if the transport considers a session to be with a > remote destination at a locator, and the locator changes during a session, > the transport layer will not recognize it and as a result the session will > fail. That, specifically, is why ILNP specifies that the locator is not > included in transport layer checksums; some would argue that it should not be > communicated to the transport at all.
Hi, Fred, Of course, I know at least this much. This is the rationale for all those ID/Loc separation. And ILNP is one of them. I'm not here to argue against ID/Loc separation. As far as I take for granted that ILNP will be our choice by RRG, I'm not arguing against ID/Loc separation. As far as I know, some ID/Loc separation was started to improve mobility; HIP would be one such example. Other LIS proposal were more focused to multi-homing; Shim6 might be, if I'm not wrong, one such example. And here, we're also primarily concerned with multi-homing to improve routing scalability, hence ILNP. Now I want to know more in depth how practically ILNP improves on routing scalability in DFZ, and how significantly? I was trying to catch this aspect by comparing - how ILNP deals with multiple Locators and - how the current Internet deals with multiple PA addresses. > > At the Application Layer, any use of a network layer address has pitfalls. > You might want to review > > http://www.ietf.org/rfc/rfc2993.txt > 2993 Architectural Implications of NAT. T. Hain. November 2000. > (Format: TXT=74136 bytes) (Status: INFORMATIONAL) > > for a reminder of why IPv4/IPv4 Network Address Translation has been a > headache. These issues remain in ILNP when the application uses a network > layer address indiscriminately; routing protocols can have difficulties > across the boundary between addressing domains, HTTP Referrals may not be > meaningful, SIP/SDP can fail when it communicates the address of a > communicant, and so on. The rule has to be that IF ONE IS GOING TO USE A > NETWORK LAYER ADDRESS one uses the address appropriate to the peer (an > "inside" address if the peer is in the same domain, and an "outside" address > in other cases), or (much better) applications confine themselves to using > application layer identifiers such as DNS names. > >> To me, it looks quite equivalent. My host will know of the two in >> existence, and will switch between the two as need arises. > > There I disagree, or disagree in part. My DNS system will need to know of all > of the addresses; my host needs to know only if it is responsible for > populating them into DNS. > > Let me draw a picture for you. > ,-. > ,---------. / \ > ,-' `+-+ +-+ \ ,-. > ,-----. +---+ ISP 1 |R+--+R| : / \ > ,-' `+DMZ+. ,+-+ +-+ : / \ > /+-+ +-+-+ `---------' ; +---+ +-+ : > / |A| \ | |DMZ| |C| | > ; +-+ : | ISP 3 +-+-+ +-+ ; > | +-+ | | | \Your / > : |B| +---+---------. : ; \Domain > \ MyDomain +-+ |DMZ| +-+ +-+ ; `-' > \ +---+ ISP 2 |R+---+R| ; > `-. ,-' `. +-+ +-+ / > `-----' `---------' \ / > `-' > > In my domain, I have two hosts: my own is A, and B is another one. In your > domain, you have some host C. When B or C want to communicate with A, they > ask DNS for A's set of addresses. Ideally, B gets A's "inside" address and C > gets A's two "outside" addresses; more probably, each will get all three, and > sort among them by discovering, in B's case, that A has an address that is > "more similar" (matches a longer subset of its prefix) than the other two, or > some of the addresses simply don't work. The question is how the DNS system > gets A's 3 addresses. A is actually only aware of the "inside" address and > will only use that; however, DNS knows the translation to the external set of > addresses, and if A is posting addresses via Dynamic DNS, will do that > translation when addresses are posted. If the DNS system isn't doing that, > then of course A will have be aware of its addresses. I think you're describing here a case of NAT, e.g., private address. In my question to Tony, I was specifically confining the case to PA addresses; multi-home sites in both ILNP and my example of the current Internet would use PA Locators or addresses. I'd like to know the performing difference in these two scenarios. > >> I assume we're talking about multi-homing, not mobility here >> specifically in this context. If it's about mobility, I can see that >> ILNP has an advantage for TCP connection is not associated with >> locator while it would be with the current IP address. > > Actually, multihoming becomes a special case of mobility. I know, but not completely. Multi-homing can be considered as slow mobility. With fast mobility, you'd be sensitive about continuity of TCP connections. With multi-homing, you'd be more relaxed and only concerned about roaming aspects. A host in a site-multi-homed host would have multiple PA addresses, and the host or remote correspondent nodes would be more concerned about which address to use in a newly initiating connection. > >> But as long as you were talking about multi-homing, you would not mean >> fast transitioning without breaking a TCP connection. You would >> implicitly mean a situation where the same host would be associated >> with a connection at one point in time and with another at a different >> point in time. Or even with two simultaneous yet separate connections. > > If the locator is irrelevant at transport and above, this also helps with the > multipath TCP case. It requires the application to send not to a given remote > address but to all of them, but it has that possibility. Of course. But, again, let's please focus on behavior in transitioning/failover across multiple-PA Locators/addresses. > >> In all these connection scenarios, I would assume that the effect >> would be the same in both cases of ILNP and the current Internet. >> >> I must be missing a critical point here. >> >> But, if I'm not, wouldn't it the description of yours apply in the >> same way to the current Internet? The same situation with multiple PA >> addresses? > > yes and no; TCP in the present internet cares a great deal about the locator, > and applications do as well. Shim6 tries to address those issues, but a shim6 > internet is not the same as the present one either. I think, we're shooting at different targets here. Your statement here is of course correct. My focus is how to reduce the DFZ routing table size. -- DY _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
