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

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

Robin,

Only follow-up for now is that IPvLX does anticipate
support for multihomed sites. Sites that are multihomed
can publish multiple ETR RLOCs in the mapping service,
and ITRs can use any/all of the available RLOCs for TE
or fault tolerance purposes.

Thanks - Fred
fred.l.templin at boeing.com

> -----Original Message-----
> From: Robin Whittle [mailto:rw at firstpr.com.au] 
> Sent: Thursday, July 19, 2007 6:13 PM
> To: ram at iab.org
> Cc: Templin, Fred L
> Subject: Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared
> 
> 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
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram