On 05 Aug 2010, at 08:26 , Patrick Frejborg wrote: > So to achieve multi-pathing you need two separate interfaces with own > locators on the node - unless BRDP is used for egress traffic of the > initiator to solve the exit routing (that I have called first mile > routing).
No. There are multiple counter-examples. I'll briefly list a few, deliberately in summary form because time is scarce. Other counter-examples also exist. A) As you suggest, BRDP can be very helpful in some situations. (I am quite keen for Teco Boot to continue his work on BRDP.) However, BRDP is not necessary to support either multi-homing or multi-path. B) If one considers a session between two correspondents, if either node has more than one valid Locator value (e.g. in the DNS, multiple L64 or L32 records), then multi-pathing and multi-homing are each supportable. C) The MILCOM 2009 paper about Site-Controlled Multi-Homing provides an example where a node can have multiple Locator values (or 1 ore more LP records that in turn point to multiple Locator records) in the DNS, but where that node only has 1 Locator value configured inside the stack of that node. In such a scenario, the site has multiple upstream links with at least 1 distinct Locator value for each upstream link. One imagines that different users/sites will make different deployment decisions. ILNP supports multiple deployment models, leaving it up to the users/sites to select one that is appropriate for that user/site. > How does the responder know to which border routers subflow > A and B belongs in order to achieve separate and symmetric paths ? There are multiple deployment scenarios that work fine. I'll list two, in summary form due to lack of time, but others also exist. The MILCOM 2009 on Site-Controlled Multi-homing describes at least one scenario in some detail. W) The responder does not need to know if the responder's site is using the deployment approach from the above MILCOM 2009 paper. The site border routers can be configured with whatever multi-homing (and/or multi-path) policy that the site wishes. X) The responder either knows or can learn that the initiator has multiple Locator values (or 1 or more LP records pointing to multiple Locator values). The responder simply sends the packet out to the different Destination Locator values. Provided that those different Locator values are on different subnetworks, ordinary LPM routing will cause the packets to travel down (entirely, partly, or slightly -- depending on how much topological variance exists in the Locators used) different paths. There are no guarantees of symmetric routing in today's Internet. Similarly, there are no guarantees of symmetric routing in ILNP. The path taken in one direction might or might not be the inverse of the path taken in the other direction. Ignoring other issues, the deployed BGP routing system means that guarantees about symmetric routing cannot be made. > BRDP is replacing default gateway mechanism, ... I would say that BRDP can be used to supplement/enhance the usual default gateway mechanism. I would not say "replace". > it seems that something should be added for the first packets > of a subflow at the border router so that the responder can > "setup" the returning subflows to the correct border routers. I don't understand those words. > Also which component is applying muxing of packets from the > application level and concurrently load-balance packets between the > paths? > I.e. two first packets are sent on path A and following packets are > sent on path B, then following on path A etc I also don't understand those words. If one considers TCP as an example, then the TCP instance simply sees the information as it arrives at the node. Because ILNP means that the TCP instance is not bound to any particular Locator, the TCP instance is oblivious about which path a particular received TCP segment might have travelled. Similarly, the transmitting TCP instance is oblivious about whether multiple paths are in use xor a single path is in use -- and also oblivious about which transmitted TCP segment might travel which path. The ordinary TCP operation will handle the information that arrived, perform the usual TCP operations (reassembling TCP segments, sending TCP ACKs, etc) and will pass the received information up to the application using the existing APIs. So no application changes are needed either. Yours, Ran _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
