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

["Templin, Fred L" <[e-mail]>]

Robin - see below: 

> Thanks for clarifying my understanding of IPvLX to some extent.  I
> still don't have anything like a clear enough understanding of it
> to compare it with the other schemes.
> 
> Is IPvLX intended to help with IPv4 in respect of multihoming,
> portability, TE, splitting up existing space into finer and more
> flexibly used sections for more users and/or with  reduction in
> BPG advertisements and/or churn in IPv4?

IPvLX anticipates a future in which new growth within sites 
will be dominated by IPv6 applications and services, and that
the IPv4 growth curve will level off. This does not mean that
IPv4 applications and services would disappear, but rather
that pressures for multihoming, TE, etc. would be taken off
the IPv4 DFZ and instead be satisfied by a map-and-encaps
scheme that maps potentially many IPv4 RLOCs to the same IPv6
EID. Then, as more applications and services are transitioned
to IPv6, IPv4 address space could be reclaimed and redistributed
in finer-grained chunks such that more and more of the IPv4
address space is used as RLOCs for a site (and not EIDs).  
 
> If not, then as with Six/One, I don't think IPvLX helps with the
> most pressing problems of the foreseeable future - and so is not
> comparable to LISP, eFIT-APT or Ivip.
> 
> If your proposal does help with IPv4 communications, with
> non-upgraded hosts - for instance resulting in immediate or
> long-term reduction in the size of the global BGP routing table,
> and/or in improvements to multihoming, portability or TE then it
> would be great if you could explain on the list exactly how this
> works, with network diagrams, examples of deployment etc.

IPvLX leaves existing IPv4 communications alone and encourages
future growth in IPv6. It also encourages a longer-term trend
toward using IPv4 addresses more as RLOCs and less as EIDs.
 
> Can IPv4 hosts on non-upgraded networks send packets to IPv4 hosts
> on upgraded networks?  If not, then I think IPvLX suffers from the
> same problem as LISP-NERD or LISP-CONS - and so is not
> incrementally deployable because early adopters (really any
> adopters until adoption is universal) suffer loss of reachability
> Early adopters suffer the worst costs or barriers, since hosts in
> virtually no other networks will be able to reach their hosts.

No; there would be no loss of reachability. Non-upgraded
networks could communicate with upgraded networks using
IPv4 just as they do today. By proof of concept, Microsoft
Teredo is beginning to emerge in "upgraded" networks today
vis-a-vis Windows Vista deployment yet IPv4 remains fully
functional in those networks. IPvLX very closely parallels
the Microsoft Teredo model - both in terms of functional
behavior and anticipated deployment model.
 
> Although there is no detailed documentation of how eFIT-APT could
> be incrementally deployed (at least in terms of reachability and
> what is and is not advertised in BGP), I imagined a way it could
> be done while retaining reachability from non-upgraded networks.
> However, this defers the reduction in the size of the BPG routing
> table until either all networks are upgraded, or until enough of
> them are that some upgraded networks don't mind about not being
> reachable from those networks which are not - and so stop
> advertising their prefixes in BPG.
> 
> 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.

> LISP-NERD/CONS and eFIT-APT all have slow-changing databases which
> carry instructions for the ITR-ETR system on how to cope with
> short-term traffic flow requirements, such as loss of reachability
> on one link, requiring packets to be tunneled to another ETR in
> order to restore communications.  The short-term decisions are
> made by the ITR-ETR and the mapping data does not change at all
> during multihoming service restoration.  This means a more complex
> database and *much* more complex ITR-ETR functionality, with much
> more communication between ITRs, ETRs and in some cases recipients
> of tunneled packets which are not ETRs which are ready to handle
> the packets.  This introduces a much greater burden of complexity
> in order to adequately protect against attacks and other security
> problems.
> 
> In short, LISP-NERD/CONS and eFIT-APT all card-code short-term
> behavior into the system itself, and make it configurable to some
> extent by parameters in the mapping database.
> 
> Also, LISP-NERD/CONS and eFIT-APT do not attempt to assist with
> mobile-IP - because their database distribution systems are too
> slow with a mobile host's requirement that traffic flow to one ETR
> or another in the different networks it has connections with.
> 
> Ivip is completely different.  The database is simple and intended
> to be very rapidly changed.  Ivip does not attempt any
> reachability testing or require its ITRs or ETRs to make any
> decisions, such as for TE, multihoming service restoration or for
> mobility.  This means Ivip can be used to support with mobile IP
> just as it supports multihoming restoration, portability, finer
> splitting of the address space among many more end-users etc. -
> without actually containing any special database information or
> ITR functions to support these separate applications.
> 
> 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.
 
> 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.

>   and of how IPv4 packets flow in both
>   directions between hosts in firstly two upgraded networks and
>   secondly in one upgraded and one non-upgraded network.

IPv4 works no differently between upgraded and non-upgraded
networks.

>   Describe the possible placement of upgraded or new routers.

Upgraded or new routers are deployed as site border routers.
 
>   Describe the new features which are required in routers and
>   how feasible these are to implement in the FIBs of current
>   routers, with firmware upgrades.  The rest has to be done
>   in the main CPU.  In both cases, it is important to discuss
>   the communications, CPU and memory requirements of these new
>   features for a reasonably widely deployed scenario.  Also,
>   in the long-term future, can scaling be achieved by
>   parallel routers, servers etc. rather than having to ramp
>   up performance of routers which can't have their load split
>   amongst others.  (eFIT-APT seems to suffer here, because all
>   the ITR and ETR work has to be done in Customer Edge routers
>   of provider networks.)

The neew feature for routers is the mapping engine.
 
>   Examples of packets which are used in IPv4 host communications
>   and separate examples for IPv6.

IPv4 host communications is done exactly as it is today.
IPv6 host communications is done by tunneling IPv6 over IPv4.

>   What other servers, databases, distribution systems etc.
>   are required.

The current IPvLX proposal assumes a DNS mapping system;
future versions could use a different mapping mechanism.
 
> Then, ideally, you could write something about IPvLX for each of
> the underlines headings in my comparison.
> 
> I would link to your message in the list or perhaps splice this
> into my page:
> 
>   http://www.firstpr.com.au/ip/ivip/comp/
> 
>     - Robin

Thanks - Fred
[e-mail] 

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