[rrg] Rejecting all but Strategy A

[Pekka Nikander]

>>>               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.

To clarify what I have already stated:  As far as I can see, HIP was  
never meant to be a solution to the RRG problem (HIP started in 1999,  
RRG around 2006 IIRC).  HIP is an architectural change, and its  
official IETF status is, if I understand correctly, "ongoing  
experiment".  People are encouraged to run HIP in the Internet and  
report any experiences to the HIP-RG.  There are open source  
implementations for Linux, FreeBSD, Windows, and Mac OS X.

As a protocol and architecture, HIP is basically ready; it has been so  
for 1-2 years now.  There are a few open loops, such as the details of  
NAT traversals, but they are gradually being closed. There has also  
been some discussions on reopening the discussion of whether it should  
re-chartered for standards track, but I have only heard rumours, not  
been active myself.

What comes to HIP and RRG, I do believe that HIP *could* help in  
solving the RRG problem.  It *could* form a core for what people now  
call "Strategy B" solutions, and a HIP-proxy based solution *could* be  
deployed as a "Strategy A" solution.  I don't know the details of  
LISP, but the recent discussion between Dino and me seem to indicate  
that HIP proxy and LISP xTRs are functionally close enough so that a  
HIP proxy could be "plugged in" to the LISP architecture, yielding a  
"Strategy A" HIP-based network-level solution that could eventually  
lead to full HIP deployment at all hosts, which *could* lead to an  
architecture where renumbering is never needed due to full transparent  
support of multiple IP addresses at all hosts.

But, obviously, developing a HIP-based RRG solution would require  
work.  Few if any HIP folks are active at the RRG, AFAIK.  So, there  
doesn't seem to be anyone who would be interested enough to invest the  
time and effort.  (For example, I don't normally have enough of time  
to browse the RRG ML...)

--Pekka