Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared

[Robin Whittle <[e-mail]>]

Thanks Fred for clarifying my understanding of IPvLX.

I understand now that it is to support IPv6 user traffic over IPv4
networks, with the aim of encouraging IPv6 adoption and without (I
think) further burdening the global BGP routing tables for either
IPv4 or IPv6.

You wrote, in part:

>> How does IPvLX handle the requirement that a multihoming system
>> short-term changes to traffic flow?  I think service restoration
>> for a multihomed link is an example of what Eliot called
>> "operational state"?  This is an important aspect of architectural
>> goals in which Ivip differs completely from LISP or eFIT-APT.
> 
> I didn't understand this.

The primary goal of LISP, eFIT-APT and Ivip is to work with IPv4
traffic over the IPv4 routing system - or IPv6 traffic over the
IPv6 routing system - and in both cases to enable end-users to
achieve multihoming without having to advertise their address
space as a separate BGP prefix, and therefore without requiring
any change to BGP advertisements when their link from ISP A goes
down and they need their packets to come in via a link from ISP B.

Ivip enables the user to achieve multihoming service restoration
via fast database updates, driven by a user-provided mechanism,
whereas LISP and eFIT-APT have slower database distribution
systems and have the service restoration function built in to
their ITRs, ETRs etc.

I now realise that your proposal doesn't mention "multihoming".
This, and the fact that your proposal is only for IPv6 user
traffic, means that it is trying to solve different problems from
those which LISP, eFIT-APT and Ivip are trying to tackle.


>> Ivip more closely follows what I think is a common IETF
>> philosophy: single function, open-ended, building blocks which can
>> be used in combination with other building blocks to solve a wide
>> variety of problems, without having to create a monolithic system
>> for each particular problem.  (I don't know of a formal statement
>> of this, but it is evident from the whole nature of TCP/IP design,
>> DNS,  HTTP etc.)
> 
> I don't see any questions regarding IPvLX in this.

OK - I was still discussing the differences between Ivip and the
other proposals' approach to multihoming service restoration.


>> Assuming IPvLX helps with ordinary IPv4 communications, it would
>> be great if you could explain on this list how IPvLX would be
>> deployed:
>>
>>   Give a fully detailed example of the BGP or other benefits it
>>   brings to IPv4,
> 
> The benefits to IPv4 are that it encourages new growth in
> IPv6 instead of IPv4.

I think any system which makes IPv6 easier to adopt, in a scalable
manner, is a good idea.  I don't know enough about IPv6 and the
various approaches such as 6to4 to be able to fully discern how
IPvLX, Teredo, 6to4 and others compare in terms of scalability and
functionality.

Perhaps if you wrote something comparing the long-term scaling and
interoperability of these three systems, and any others which are
relevant, this would help me and others through this complex set
of issues.

I have added links to your message and this discussion from the
page where I am maintaining an updated copy of my comparison:

  http://www.firstpr.com.au/ip/ivip/comp/#IPvLX


  - Robin


_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram