Short version: I broadly agree with Brian's "... my preference is
to recommend development work on strategy A and
continued R&D on strategy B."
Hi Brian,
Thanks for your detailed response.
You wrote, in part:
>> HIP has been mentioned, but no-one seems to be
>> proposing it as a scalable routing solution.
>
> I think Pekka observed that this wasn't even a goal. (My quick answer
> is that it only becomes a routing solution if it solves the same
> mapping problem that strategy A generates.)
I don't understand your comment, but if the HIP proponents do not see
it as a solution to the routing scaling problem, then unless someone
on the RRG feels strongly that it is, then HIP is out of scope for
discussion and for matching against any of Bill's architectures.
> Shim6 has also been mentioned, as a mitigation of some the issues
> with the multiprefix PA model. That is already chartered IETF work
> with full documentation.
Yes - and Shim6 matches Bill's Strategy G:
http://bill.herrin.us/network/rrgarchitectures.html
http://www.firstpr.com.au/ip/ivip/rrgarch/
>> Every possible Strategy B approach would be vastly harder to have
>> adopted by the majority of end-user networks which want multihoming,
>> TE and portability (or its functional equivalent) than any Strategy A
>> approach, for at least two reasons:
>>
>> 1 - Strategy B solutions require most or all current Internet users
>> to adopt IPv6 - and furthermore IPv6 with a modified host
>> stack, API and applications.
>
> The first half of this is increasingly likely to happen anyway.
So people have been saying since 1996. I will believe it when I see it.
> It isn't certain that the API and apps have to be touched; rolling out new
> stacks over five to ten years really isn't a valid objection.
I agree that if only the stacks need to be changed, then that would
be a much lower impediment - especially with IPv6 which is hardly
used at present.
ILNP supposedly requires no API or application changes - but as far
as I can see, it won't handle referrals, or at least won't provide
multihoming for referrals. Ran suggests rewriting apps to avoid the
need for referrals. I think this would be a major barrier to
adoption. My next two messages concern ILNP.
Would SIP need to be changed to avoid referrals or to do the same
thing in ILNP-friendly ways?
> But I fully agree: strategy B == IPv6.
OK.
>> 2 - Strategy B solutions provides benefits to adoptors only when
>> the other host in a session (stack and relevant applications)
>> has been upgraded too. So until almost all networks and their
>> hosts adopted it, the scheme could only provide multihoming for
>> a fraction of communication sessions.
>
> This is true. The question is whether this (piecemeal incentives, highly
> distributed low costs) is really less effective than the incentives to pay
> the highly concentrated per-network costs of strategy A.
With Ivip, I anticipate that the businesses which provide the mapping
service and who rent out Mapped Address Blocks, splitting them up
into thousands of smaller pieces for end-user networks to split
further into micronets (EIDs) will be offering a valuable service
from the start. This is because Ivip supports multihoming, TE and
portability, including for all packets coming from hosts in
non-upgraded networks. I expect this to be a profitable business,
not some cold, dead, thing we reluctantly put millions of dollars
into in order to avoid a future DFZ meltdown.
>> Also, I argue that any approach which involves pushing
>> responsibilities and management traffic to all hosts (all potential
>> Strategy B approaches) is fundamentally flawed:
>>
>> http://www.irtf.org/pipermail/rrg/2008-November/000233.html
>
> Highly distributed = scaleable. And in any cases, hosts have always
> been responsible for traffic management (that's called TCP)
> and approaches like SCTP and the proposed multipath TCP extend that.
> So I don't think we should condemn this in the abstract.
Yes - but the existing host functions (with the possible exception of
some of SCTP's functions) are all coping with things which must be
handled in the hosts.
Multihoming, TE and portability can be handled in the network,
without touching the hosts or burdening them with the resulting
management traffic.
I think ILNP is not an exact match for Bill's Strategy B, but it is
close enough for general discussion. That adds a lot of state to
each host for every IP address the host communicates with. There is
extra management traffic, in the form of longer DNS responses and
sending and receiving Nonce Destination Options. That requires more
code to handle the resulting PMTUD problems, and as far as I can see,
will restrict the maximum packet length any application can send to
20 bytes less than whatever it would otherwise be.
I think ILNP is an absolutely minimal proposal. If fully developed,
it would need to be more complex, I am sure.
HIP is another potential host-based approach, though it too does not
seem to match Strategy B directly. HIP is much more complicated,
with every host being required to do fancy cryptography, and there
being several RTTs of exchanges between two hosts before any real
work can be done.
http://infrahip.hiit.fi/index.php?index=how
A fully developed HIP would involve multiple cryptography options,
further increasing complexity.
I stand by my objections to forcing such complexity and extra traffic
onto every host in the future IPv6 Net - for things which happen in
the network and can best be handled there: multihoming, TE and the
need for portability as the only reasonable way (for all but the
smallest networks) of selecting a new ISP without major costs and risks.
>> I find it impossible to imagine how a Strategy B solution could
>> succeed if we fail to solve the problem via the best one or more
>> Strategy A solutions being properly developed and offered for adoption.
>>
>> RRG rejection of Strategy B solutions is not to suggest that people
>> shouldn't work on such schemes. Just that we have no confidence that
>> any such scheme could turn out to be technically better and/or easier
>> to have widely adopted than a well developed version of the best of
>> the Strategy A schemes.
>
>
>> Of course, if the best efforts with Strategy A schemes fails, then
>> everything would be up for reconsideration. However, that is a
>> potential scenario in the post-2020 future. Then, any Strategy B
>> solution would still involve much higher barriers to development and
>> adoption than any Strategy A solution.
>
> Exactly. Which is why my preference is to recommend development work
> on strategy A and continued R&D on strategy B; I'd be very concerned
> if we shrugged our shoulders and dropped it for 12 years.
OK. I agree - except I guess we will recommend something more
specific than any architecture which fits Bill's Strategy A definition.
My notion of the RRG rejecting Strategy B - and any other comparable
elimination schemes which involve new host functionality and
management traffic - is that we are rejecting the notion of
considering any such scheme for recommendation to the IETF for
development in order to solve the routing scaling problem in the
foreseeable future.
The RRG not recommending any such architecture for IETF development
is not a message to developers to stop working on such things.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
