On Fri, Aug 6, 2010 at 3:51 PM, RJ Atkinson <[email protected]> wrote:
>>> 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.
Had again a look on the paper, think you are referring section D.
Mobile networks with ILNP, right?
That is a handover scenario from L1 to L3 described - what I'm looking
for to have MPTCP having two concurrent subflows traversing over both
L1 and L3 simultaneously
>
> 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.
Sorry, I should have used two logical networks, so you have configure
multi-netting (secondary addresses) on the hosts, routers, firewalls
etc
>
> 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.
To me that is two logical networks with two separate 0/0 routes
>
>> - 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.
Right
>
> 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.
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
>
> 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.
Understood, but DNS do not tell the initaitor that for the returned
locator A value the initiator should use local locator 1, for returned
locator B the initiator should use local locator 2. If it do then the
subflows are always established as
locator1 -----subflow1-------locatorA
initiator responder
locator2------subflow2------locatorB
>
>> 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.
True - but you might end up with asymmetric paths between two
multi-homed sites - if you are setting different preference values in
DNS one path is preferred and with equal values then the nodes choose
randomly (?) which locator is used unless there is some local policy
at the node (that are in sync)
>
> 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.
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).
>
> 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.
>
True, but many enterprises would be happy to get rid of the BGP tuning
- with the locator header&MPTCP you just connect your multi-homed site
to Internet, announce your attachment point (ALOC1, ALOC2) together
with ELOC values in DNS - let the transport protocol do the
load-balance tuning (which is reacting instantly to the traffic
situation). BGP tuning is usually done after somebody have suffered
and complained....your services has already suffered...
So with MPTCP & locator header you have reached a better service
level with less cost than current multi-homing implementation.
>
> 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.
>
Right, but ILNP do nothing to better support MPTCP or SCTP than what
we have today - it is a status quo form their perspective
-- patte
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
