On 06 Aug 2010, at 04:40 , Patrick Frejborg wrote: > On Thu, Aug 5, 2010 at 5:34 PM, RJ Atkinson <[email protected]> wrote: >> 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. > > > And this is my point - if a node have several locator values you might > need to have > - two separate networks between the node and the border routers
That is a confusion. 1) Those assumptions are never true when one deploys using (C) above. 2) Further, a node never needs "two separate networks between the node and the border routers" to have two (or more) Locator values. The trivial example here is multi-netting; other examples also exist. 3) A node doesn't even need to have more than 1 network interface in order to have more than 1 Locator value at the same time. Multi-netting is again a trivial example here; other examples also exist. > - some routing mechanism in the node, when should the node use locator > 1 and when should it use locator 2? The node may choose any valid Locator value for itself, among the set of valid Locators. This is a local policy matter. Similarly, the node may choose any valid Locator value for the correspondent, among the set of valid Locators. This is also a local policy matter. Kindly recall that Locator records in the DNS have Preference values. An obvious use for those Preference values is to signal the Locator frequency preference of the node associated with those Locator records. It could, for example, have multiple Locator records with equal preference, indicating a suggestion that remote nodes alternate which Locator value is used with each packet (among the equal set). ILNP doesn't require that Preference values be used this way, should a site or node prefer not to do so, but ILNP certainly does enable Preference values be used this way. > Outcome is that the operational expenditures becomes too high and I > guess that is one reason we haven't seen SCTP becoming mainstream No. Even if the node always chooses one of those locators, that node can still have multi-path transport benefits, because the site border routers are allowed to rewrite Locator values. So a site could have a policy to enable multi-path session -- where that policy exists solely within its site border routers. This eliminates any need to put any multi-path policy configuration on nodes within the site. Since this multi-path policy is really ultimately a routing policy, something which router administrators routinely do today (e.g. "weights" in IGP link-state routing protocols, "local pref" or "AS prepending" in BGP), there is substantial operational experience indicating that this is quite reasonable and not burdensome. ILNP is about providing choices to users/operators/sites. ILNP can be deployed quickly if desired, without bothering with node-specific or site-specific configuration items. Later on, if desired, nodes or routers can have additional configuration, again if and only if the site admin or node admin wishes to do so. >> 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. > > It is very true that Internet is far from symmetric but there exist > use cases where symmetric paths is a major requirement. But wouldn't > it be nice to have e.g. symmetric concurrent multipaths (as described > in the introduction of draft-ietf-mptcp-architecture-01) from your > workstations to the data center - for one session? ILNP does nothing to prevent symmetric routing. ILNP does not require symmetric routing. Folks who have an interior routing deployment that provides symmetry (e.g. between workstation & local data centre) can continue to have one with ILNP. Nothing in the ILNP specifications prevents that from continuing to work. Yours, Ran _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
