Thanks for catching the typo, we´ll correct it for the upcoming version. Albert
On Sat, Jul 26, 2014 at 9:44 AM, Rene Bartsch <[email protected]> wrote: > Am 2014-07-25 22:21, schrieb Fabio Maino: > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 12] >>> >>> Internet-Draft LISP Introduction July 2014 >>> >>> >>> 7. Initial Applications >>> >>> {{Suggested by editors: Move this section after section 8, the >>> applications should not be described before LISP has been fully >>> described. >>> >>> {{Suggested by Noel: Reorder the whole section in popularity order?}} >>> >>> As previously mentioned, it is felt that LISP will provide even the >>> earliest adopters with some useful capabilities, and that these >>> capabilities will drive early LISP deployment. >>> >>> It is very imporant to note that even when used only for >>> interoperation with existing un-modified hosts, use of LISP can still >>> provide benefits to the site which has deployed it - and, perhaps >>> even more importantly, can do so to both sides. This characteristic >>> acts to further enhance the utility for early adopters of LISP. >>> >>> Note also that this section only lists some early applications and >>> benefits. See [I-D.ietf-lisp-perspective], in the Section "Goals of >>> LISP", for a more extensive discussion of some of what LISP might >>> ultimately provide. >>> >>> 7.1. Provider Independence >>> >>> Provider independence (i.e. the ability to easily change one's >>> Internet Service Provider) is a good example of the utility of >>> separating location and identity. >>> >>> To limit global routing table size addresses need to be aggregated. >>> To that aim networks can use provider aggregatable addresses >>> ([RFC4116]) which means that the IP prefixes of networks are sub- >>> prefixes of their provider. This solutions allows to reduce >>> scalability issues of the global routing table but it means that when >>> a network switches providers it has to re-number all its devices >>> which is known to be complex in current networks [RFC5887]. >>> >>> Having separate namespaces for location and identity greatly reduces >>> the problems involved with re-numbering; an organization which moves >>> retains its EIDs (which are how most other parties refer to its >>> nodes), but is allocated new RLOCs, and the mapping system can >>> quickly provide the updated mapping from the EIDs to the new RLOCs. >>> >>> 7.2. Multi-Homing >>> >>> {{Suggested by editors: This section should be extended, it is >>> unclear the benefits that LISP brings to multihoming (.e.g, traffic >>> engineering, decoupled multihoming from the data-plane). >>> >>> >>> >>> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 13] >>> >>> Internet-Draft LISP Introduction July 2014 >>> >>> >>> Multi-homing is another place where the value of separation of >>> location and identity became apparent. There are several different >>> sub-flavours of the multi-homing problem - e.g. depending on whether >>> one wants open TCP connections to keep working, etc - and other axes >>> as well (e.g. site multi-homing versus host multi-homing). >>> >>> In particular, for the 'keep open connections up' case, without >>> separation of location and identity, with most currently deployed >>> implementations, the only currently feasible approach is to use >>> provider-independent addressses - which moves the problem into the >>> global routing system, with attendant costs. This approach is also >>> not really feasible for host multi-homing. >>> >>> 7.3. Traffic Engineering >>> >>> {{Suggestion by editors: Merge this section with the previous one, TE >>> is not practical without multihoming}} >>> >>> {{Needs a fix - not sure what.}} >>> >>> Traffic engineering (TE) [RFC3272], desirable though this capability >>> is in a global network, is currently somewhat problematic to provide >>> in the Internet. The problem, fundamentally, is that this capability >>> was not forseen when the Internet was designed, so the support for it >>> via hacks is neither clean, nor flexible. >>> >>> TE is, fundamentally, a routing issue. However, the current Internet >>> routing architecture, which is basically the Baran design of fifty >>> years ago [Baran] (a single large, distributed computation), is ill- >>> suited to provide TE. The Internet seems a long way from adopting a >>> more-advanced routing architecture, although the basic concepts for >>> such have been known for some time. [RFC1992] >>> >>> Although the identity-location mapping layer is thus a poor place, >>> architecturally, to provide TE capabilities, it is still an >>> improvement over the current routing tools available for this purpose >>> (e.g. injection of more-specific routes into the global routing >>> table). >>> >>> In addition, instead of the entire network incurring the costs >>> (through the routing system overhead), when using a mapping layer to >>> provide TE, the overhead is limited to those who are actually >>> communicating with that particular destination. >>> >>> LISP includes a number of features in the mapping system to support >>> TE. (described in Section 8.2, "Control Plane - Mapping System >>> Overview", below); more details about using LISP for TE can be found >>> in [I-D.farinacci-lisp-te]. >>> >>> >>> >>> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 14] >>> >>> Internet-Draft LISP Introduction July 2014 >>> >>> >>> Also, a number of academic papers have explored how LISP can be used >>> to do TE, and how effective it can be. See the online LISP >>> Bibliography ([Bibliography]) for information about them. >>> >>> 7.4. Routing >>> >>> {{Suggestion by editors: Remove this section, LISP is not a routing >>> protocol.}} >>> >>> Multi-homing and Traffic Engineering are both, in some sense, uses of >>> LISP for routing, but there are many other routing-related uses for >>> LISP. >>> >>> One of the major original motivations for the separation of location >>> and identity in general, and thus LISP, was to reduce the growth of >>> the routing tables in the "Internet core", the part where routes to >>> _all_ ultimate destinations must be available. LISP is expected to >>> help with this; for more detail, see Section 15.4, "LISP and Core >>> Internet Routing", below. >>> >>> LISP may also have more local applications in which it can help with >>> routing; see, for instance, [CorasBGP]. >>> >>> 7.5. Mobility >>> >>> {{Suggestion by editors: Remove this section, mobility is not in >>> charter.}} >>> >>> Mobility is yet another place where separation of location and >>> identity is a key part of a clean, efficient and high-functionality >>> solution. Considerable experimentation has been completed on doing >>> mobility with LISP. >>> >>> The mobility provided by LISP allows active sessions to survive moves >>> (provided of course that there is not a period of inaccessibility >>> which exceeds a timeout). LISP mobility also will typically have >>> better packet stretch (i.e. increase in path length) compared to >>> traditional mobility schemes, which use a home agent. >>> >>> 7.6. Traversal Across Alternate IP Versions >>> >>> Note that LISP inherently supports intermixing of various IP versions >>> for packet carriage; IPv4 packets might well be carried in IPv6, or >>> vice versa, depending on the network's configuration. >>> >>> This capability allows an island of operation of one type to be >>> automatically tunneled over a stretch of infrastucture which only >>> supports the other type. >>> >>> >>> >>> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 15] >>> >>> Internet-Draft LISP Introduction July 2014 >>> >>> >>> 7.7. Virtual Private Networks >>> >>> {{Suggestion by editors: Remove this section, not covered by any WG >>> document}} >>> >>> L2 and L3 {{Need to add text here - This used to be part of 'Local' >>> below, but we decided this was so important it deserved its own >>> section. Maybe move this up further, as it seems to be the most >>> important 'early adopter' application?}} >>> >>> The mapping-and-encapsulation nature of LISP makes it a perfect >>> candidate for VPN solutions. In this case, private parts of the VPN >>> form LISP sites and the IP addresses of devices in the private parts >>> are composing EID spaces. The interconnection between the LISP sites >>> is the public network and IP addresses in the interconnection compose >>> the RLOC space. A major advantage of using LISP to construct VPN >>> resides in the simplicity of the configurations: each xTR (i.e., VPN >>> end) is configured to query the mapping system to retrieve mappings >>> making the glue between the public (RLOC space) and the private (EID >>> space) of the VPN. >>> >>> This includes support of multi-tenancy where several private networks >>> can be carried over the same underlayer network. Thanks to the >>> instance-id field, multi-tenant network can even use the exact same >>> addresses as the xTR distinguishes the tenant based on the value of >>> the instance-id. The multiple address family support in LISP >>> mappings also allows to build private networks using a different >>> addressing family than the carrier (e.g., IPv6 over IPv4). >>> >>> 7.8. Local Uses >>> >>> {{Suggestion by editors: Remove this section. The section contains a >>> general discussion about the applicability of LISP in intra-domain >>> scenarios, however it does not describe any specific application.}} >>> >>> LISP has a number of use cases which are within purely >>> organizationally-local contexts, i.e. not in the larger Internet. >>> These fall into two categories: uses seen on the Internet (above), >>> but here on a private (and usually small scale) setting; and >>> applications which do not have a direct analog in the larger >>> Internet, and which apply only to local deployments. >>> >>> Among the former are multi-homing and IP version traversal. {{This >>> was marked to be deleted - why? The next part doesn't make sense >>> without this first?}} >>> >>> Among the latter class, non-Internet applications which have no >>> analog on the Internet, are the following example applications: >>> >>> >>> >>> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 16] >>> >>> Internet-Draft LISP Introduction July 2014 >>> >>> >>> virtual machine mobility in data centers; non-IP EID types such as L2 >>> MAC addresses, or application specific data. >>> >>> Several of the applications listed in this section are the ones which >>> have been most popular for LISP in practise; these include virtual >>> networks, and virtual machine mobility. >>> >>> These often show a synergistic tendency, in that a site which >>> installs LISP to do one, often finds that then becomes a small matter >>> to use it for the second. Given all the things which LISP can do, it >>> is hoped that this synergistic effect will continue to expand LISP's >>> uses. >>> >>> {{Preceeding paragraphs should probably get moved up into VPN >>> section?}} >>> >>> > > I suggest to add LISP with carrier grade NAT as Dual-Stack Lite > replacement in section 7. > > > Authors' Addresses >>> >>> Albert Cabellos-Aparicio (Ed.) >>> Technical University of Catalonia >>> C/Jordi Girona, s/n >>> BARCELONA 08034 >>> Spain >>> >>> Email:[email protected] >>> >> > <[email protected]>: > 147.83.30.70 does not like recipient. > Remote host said: 554 <[email protected]>: Recipient address rejected: > Access denied > Giving up on 147.83.30.70. > > > -- > Best regards, > > Rene Bartsch, B. Sc. Informatics > > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
