On Sat, Aug 7, 2010 at 4:27 AM, RJ Atkinson <[email protected]> wrote: > > 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.)
Yes - but I'm not asking for symmetric paths through Internet, asking for a simple tool to have symmetric paths across the border routers. What is happening in Internet and in the VPN are out of scope, they have their own policies. But let drop this issue for time being, we can "boil" on that in the future. > >> 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. Actually, not so much > > 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. True, the responder must have a global locator in order to be reached but the initiator can be behind NAT (as it is today). NAT has been a show stopper for SCTP, MPTCP folks have taken into account the existent of NAT. E.g. in tcpcrypt they have changed pseudo-header checksum calculation for encryption in order to traverse NAT, see section 3.3 at "The case for ubiquitous transport-level encryption". > > 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. This is the most important and interesting new discovery for me, unfortunately I do not understand how it works. My guess is that multi-path connectivity for vanilla TCP&UDP is that the node have one identifier attached with several locators so you can have several transport connections available, even simultaneously (wondering how the application asks to setup several transport connections). But there is no demultiplexing/multiplexing of packets at the stack, the stack chose one path at the time - if one fails the stack switches to the another path. Or how should I understand your statement of multi-path connectivity for vanilla TCP/UDP?? I can't find the answer in papers you pointed out, but as you probably know from the past I'm a slow learner :-) > > (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.) > I have no problem with that, think it is a good place to start with upgrading some network devices to get the transition started but not stop there - a stack will be upgraded when there are good enough incentives. -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
