On 2009-02-17 05:17, Scott Brim wrote:
> marcelo bagnulo braun allegedly wrote on 02 16 2009 2:47 AM:
>> Hi Scott,
>>
>> Scott Brim escribió:
>>> A few thoughts on this quick draft:
>>>
>>> Pure higher-layer approaches aren't acceptable:
>>>
>>> - We knew that already, for operational reasons other than
>>> renumbering, for example the shim6 argument.
>>>
>> what is the shim6 argument?
>
> The argument that took place between the IETF and network operators when
> shim6 was recommended.
SHIM6 is in development, so I don't think it's ever been recommended yet,
and anyway it's not the RRG's job to decide. So can we just
say that solutions above the network layer (including shim6, sctp
and multipath transport) are simply out of scope: the RRG has decided
not to work on them. Anything else is speculation.
>
>>> - But that doesn't mean those technologies aren't essential, because
>>> even if an endpoint only has a single locator within a domain,
>>> both endpoints and networks will be multihomed and/or mobile, so
>>> they will at least appear to have multiple locators in global
>>> routing. Shim6, HIP, SCTP, Multipath ... all are potentially very
>>> useful. It's probably outside of the scope of RRG since they do
>>> nothing to solve routing scaling,
>> what do you mean they do nothing to solve the routing scalability?
>> If every site and host uses only PA addresses, the routing system would
>> scale in the order of ISPs, reducing the contribution by the multihomed
>> sites.
>
> But that won't happen, because it requires site renumbering, multiple
> locators per host within a domain, extra policy management and so on --
> the things we discovered were operational showstoppers. The host-based
> mechanisms are vitally important but not as solutions to routing problems.
Actually, they are things we opined are currently viewed as operational
showstoppers. I believe the telcos used to view TCP/IP as an operational
showstopper. It just isn't worth the argument; just say that the RRG decided
not to consider these as in scope.
Brian
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
