Hi Bill,
|> |> / RFC 1887 4.4.2 is obviously not functional with *currently |deployed |> |> / network stacks*. It would need the kind of software described in |> |> / strategy B or H in order to be viable. Or do you disagree? |> |> |> |> It depends. |> | |> |If it's conditionally functional and the conditions aren't met then |> |it's not functional. Right? |> |> Not agreed at all!! |> Why block a good solution for certain use cases, because there are |(few?) |> other use cases that cannot use it? |> Why force an imperfect solution that has (strong?) disadvantages for |some |> (few?) use cases? | |Teco, | |I think you might be missing my point. I wasn't making a value |judgment on the reasonableness of using multiple addresses in order to |multihome. I was simply observing that the users have spoken and what |they've said is that the currently available tools and protocols are |unacceptable. | |Multiple-PA multihoming is conditional on a number of factors which, |in current practice, aren't true. So if we want a multiple-PA solution |like strategy B or H, its necessary to rearrange things so that those |conditions -are- true. Saying "go use it" when there's not an adequate |toolset to go use is really no different than the "do nothing" |strategy. I say "go on with strategy B / H". I am not saying users should have used PA multi-homing, even if there was no adequate toolset. If something is missing, we can fix it. |Anyway, if you really want to rehash the "why's" in detail, that's a |subject for another thread. I just want the "Summary of architectural solution space" to be neutral and to be based on facts. |> By the way, the term SID could be somewhat misleading. Lets |distinguish |> transport layer ID (connection ID) from session ID. | |Would you expand on that? I'm thinking of a session as an ID that |conceptually speaking, lasts from the TCP SYN to the TCP FIN. Is there |a better definition of session? What's the definition of transport |layer ID? For transport protocols, the correct term is connection. A TCP connection is identified by a pair of sockets (RFC793). One could say UDP is connectionless. In the TCP/IP model (e.g. RFC1122), there is no concept of a _session layer_ nor _session_. Although there are IETF protocols that act on a session layer (e.g. SIP), for discussion on TCP (and even UDP) I prefer the term connection. Use CID for this? (Shim6 uses ULID: Upper Layer ID). (SIP: Recently, there is I-D on Session-ID posted, with xref to UUID (RFC4122). In this proposal, IP addresses are NOT used for Session_IDs) Teco. _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
