From: Tony Li [mailto:[EMAIL PROTECTED] <snip>
>My concern is that if we turn towards map-&-encap solutions, where we can no longer actually run hosts in the native Internet architecture (i.e., without encapsulation), we have, in some sense, >fundamentally given up on the ability of the host to act as a first class element in that architecture. >Instead, it must now be shielded, protected from reality and encased in its private bubble of non-reality. >Put another way: I see the strong appeal of a recursive architecture and I embrace that portion of the goal. However, all recursion starts with a base case, and it troubles me that the host cannot be an element of that base case. >It implies that the base is flawed and has limitations in its functionality. Noel likes to say that the measure of an architecture is its ability to adapt to new requirements that are not yet forseen. >What new requirements will arise in the base architecture where the fundamental lack of host participation will cripple us? Tony, Thank you for this reply. Unfortunately, I fear that you didn't precisely state your insights on this posting such as you did on your previous posting. (Or, if you did, I somehow didn't clue in.) I therefore suspect that my reply here will not address your actual concern. If so, could you please re-state your insights using different wording? Map-and-encaps shields the host from knowing the actual network topology such that an arbitrarily complex network topology can be created that is transparent to the end user host as well as to other networks. This allows the Internet to actually consist of a series of arbitrarily dense hierarchical systems each on a local basis. The only requirement is that each local system interface with other systems at the same level of recursion in which it entered (i.e., the ingress and egress interface(s) be at the same recursion level). This gives the network provider a great deal of flexibility to address tomorrow's unforeseen requirements. I believe that this is A Good Thing because we have repeatedly confronted huge network deployments that could not easily be supported by two tiered (for IGP) network design hierarchies. To use your wording, we in Boeing have known since circa 1993 that IP is "flawed" in that manner because we repeatedly have broken IP products and routing by our vast size. Consequently, we eventually invented multi-tiered solutions for such large deployments (e.g., when I last dealt with Boeing's Corporate Enterprise network it was a 3-tiered hierarchical IGP infrastructure). I can well imagine that similar scaling problems also exist for EGP, though I have not worked in that domain myself. I do not resonate with your desire that the host should have insight into network topology. Perhaps this is because my first protocols were BSC and SNA. I am very familiar with the weaknesses of those systems including the operational kludges we had to endure to get them to scale into large deployments (e.g., source routing -- ouch!!). The reason I became excited about IP almost two decades ago was because IP freed the host from having to know anything about the network. In my way of thinking, this is a fundamental source of the power and attractiveness of IP. Specifically, I do not want the host to know about the network design because, whenever such knowledge is required, it ultimately creates a configuration nightmare for the large end user. I believe that map-and-encaps should solely be a network infrastructure design alternative. To be effective, the hosts should not be aware that map-and-encaps (or any other network topology tool) exists. In my biased opinion this means that claims such as "LISP provides an identifier-locator split" is fundamentally unrelated to the fact that HIP provides an identifier-locator split. Quite obviously, HIP does so in a manner that is real to the host (including applications) while LISP does so in a manner that is known to routers only. [My own bias is that LISP's claims in this regard are marketing while HIP's claims are close to what the ROAD Group originally intended.] --Eric _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
