Patrick,
On Aug 6, 2010, at 08:09 MDT, Patrick Frejborg wrote:
> On Fri, Aug 6, 2010 at 3:51 PM, RJ Atkinson <[email protected]> wrote:
[--snip--]
>> 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
I would note:
a) This is no different than what happens in today's deployment of IPv4 and
IPv6.
b) You may be asking ILNP to do something it isn't necessarily designed to do
out of the gate -- or, perhaps, won't do without assistance from something like
BRDP or an equivalent mechanism that, I believe, Tony Li may have pointed out
on the mailing list last month.
On a related note, at least wrt IPv6, I would also point out that there are
discussions occurring in 6MAN right now wrt how to accomplish distribution of
address selection policy on hosts within an "organization". Please refer to
slide 6 of the following given at IETF 78:
http://tools.ietf.org/agenda/78/slides/6man-5.pdf
In summary, it may be best to avoid "boiling the ocean" with respect to "v1" of
ILNP (or, for that matter, any other protocol in any IETF WG), but keep in mind
a few things:
a) Other WG's in the IETF may already be looking at and/or working on solving
for these scenarios, (cf: 6MAN + address selection policy),
b) In the IETF, new WG's /may/ get formed[1] or I-D's adopted by existing WG's
that are unrelated to ILNP, since some of the scenarios you (and, others) point
out /aren't unique to ILNP/;
c) Other work related to ILNP may get deferred until a later time, depending
on the usual variety of factors: complexity of the problem to be solved,
volunteer's time to do the work, urgency to solve the problem to meet certain
deployment scenarios, etc.
IPv4 wasn't perfected in one "go" and, instead, it took a multi-decade process
of incremental improvements to get to where it's at today. (Hopefully, ILNP
doesn't take that same amount of time). We shouldn't underestimate that there
are a variety of scenarios/deployments (please note I didn't use the word
"all") where ILNP can be used, today, that are no worse (and, in some cases
better) than today's deployments. If the IETF were to take up work on ILNP,
hopefully a ILNP WG (or, more specifically, it's charter) would coordinate
(but, not necessarily take over) these related efforts, where appropriate, to
reasonably maximize the number of deployment scenarios that ILNP can be
considered for.
Just my USD $0.02,
-shane
[1] Perhaps not particularly good examples, but:
http://tools.ietf.org/html/draft-carpenter-referral-ps-00
http://tools.ietf.org/html/draft-mrw-behave-nat66-02
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
