[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] On "jack-down" models
|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.
|> posits the
|> use of multiple parallel connections between hosts, striping data
|> these connections to instantiate a single, address-agile transport
|> Implicit in this structure is a mechanism for the host to recognize
|> these individual connections are part of a greater aggregated
|You get that as well when middle-boxes load-split ingress and egress
|traffic. The transport connection in the host just sees a
|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
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
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.
to unsubscribe send a message to firstname.lastname@example.org 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