Dino,
|Tony, that is what we recommend in LISP. So we don't have to re- |address the core. We force the re-addressing of sites that don't |currently have PI blocks. We also are loose about stating that sites |can use PA blocks for EIDs. But with the later, the namespace is not |mutually exclusive. That is okay, if the two never cross. Thanks for the correction. |> Handley |> posits the |> use of multiple parallel connections between hosts, striping data |> across |> these connections to instantiate a single, address-agile transport |> layer. |> Implicit in this structure is a mechanism for the host to recognize |> that |> these individual connections are part of a greater aggregated |> connection. | |You get that as well when middle-boxes load-split ingress and egress |traffic. The transport connection in the host just sees a |32-bit value |as a connection ID. Ok, but you don't get to take advantage of the parallel paths between the end host and the middle box(es). Think of all of the time and effort that folks have put into ECMP routing. Doesn't it make some sense that they will want to eventually propagate this all the way back to the host? |I don't see this mechanistically any different than Shim6 or Six/One. |I look forward to more details of Mark's proposal so we can see the |differences. If I understand it, there's a drastic difference. First, all of the multihoming issues are dealt with by layer 4 (and possibly above). Individual transport connections would just use vanilla v4 addressing as it's used today, complete with using the address as identification for the component connection. These would then get tied together by a stat. muxing layer. That would leave routing completely and wholly unchanged, and allow upgraded hosts to migrate to pure PA addressing without issues. Upgraded hosts could still interoperate with legacy hosts using legacy transport mechanisms. Tony -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
