First, I'll note that I concur with what Shane and Tony have already said. I can't improve on their words, so this note will seek to address some specific different topics.
On 06 Aug 2010, at 10:09 , Patrick Frejborg wrote: > And how do you ensure that there are symmetric paths between nodes > when local policies are applied on the nodes - the node policies > should be in sync Given 2 arbitrary sites, there can be no guarantee that the site/node operational policies will be compatible in a way that permits symmetric paths. For example, site A might desire symmetric paths as its highest policy preference, but site B quite commonly might desire the lowest-cost egress path as its highest priority. (Please also recall tli's comments about how transit-domain policy impacts things.) > Agreed - but to ensure that there is always symmetric multipath the > egress border router 1 (the router in front of the responder) should > follow up incoming flows so it can decide if this flow arrived via > router 1 or not. If not then most likely the flow was established over > the other egress border router 2 - then policy route the response flow > from the responder via border router 2 (in case the responder uses > border router 1 as the 0/0 path). As noted above, that operational practice might well violate the preferred operational policy of the site. In the most obvious case, many sites today always prefer the lowest-cost egress path for all packets leaving that site. ILNP enables various things not enabled in the deployed IP Internet, and provides user options about their deployment models. However, no network-layer protocol can force all operational sites to adopt particular operational policies; that simply is beyond the scope of an IRTF (or even IETF) protocol specification. > So with MPTCP & locator header you have reached a better service > level with less cost than current multi-homing implementation. It is not obvious to me that the above claim is correct. (e.g. consider tli's previous comment about how transit domain routing policy impacts the path taken by transit packets, etc.) > Right, but ILNP do nothing to better support MPTCP or SCTP than what > we have today - it is a status quo form their perspective I think we disagree there. I believe ILNP enables a set of operational policy options and deployment model options that are either impractical today or not possible today. For example, ILNP's Locator rewriting is a native capability that doesn't break end-to-end sessions, unlike IPv4 NAT, which tends to break TCP/UDP/SCTP in various ways -- and requires special TCP/UDP pseudo-header checksum modification code inside the NAT device in any event). I think that can combine with the MP/TCP work proposed by others (e.g. Mark Handley) in constructive ways. Separately, using ILNP with today's already universally deployed TCP/UDP can enable multi-path connectivity -- without requiring the TCP or UDP upgrades/modifications that are required (e.g. work by Mark Handley and others) for multi-path to work with deployed IPv4 or IPv6. (CAVEAT: Of course, support for ILNP is its own stack upgrade; different folks within the Routing RG have various opinions about the practicality of various sorts of stack upgrade.) Yours, Ran _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
