Hi, Below are my comments on the introduction draft.
Thanks! Albert [snip] > This likely resulted not just from lack of insight, but also the fact > that extra mechanism is needed to support this separation (and in the Typo, "that *an* extra mechanism" > early days there were no resources to spare), as well as the lack of > need for it in the smaller networks of the time. (It is a truism of > system design that small systems can get away with doing two things > with one mechanism, in a way that usually will not work when the > system gets much larger.) > > The ISO protocol architecture took steps in this direction [NSAP], > but to the Internet community the necessity of a clear separation was > definitively shown by Saltzer. [RFC1498] Later work expanded on > Saltzer's, and tied his separation concepts into the fate-sharing > concepts of Clark. [Clark], [Chiappa] > > The separation of location and identity is a step which has recently > been identified by the IRTF as a critically necessary evolutionary > architectural step for the Internet. However, it has taken some time > for this requirement to be generally accepted by the Internet > engineering community at large, although it seems that this may > finally be happening. > > The LISP system for separation of location and identity resulted from > the discussions of this topic at the Amsterdam IAB Routing and > Addressing Workshop, which took place in October 2006. [RFC4984] > > A small group of like-minded personnel from various scattered > locations within Cisco, spontaneously formed immediately after that > workshop, to work on an idea that came out of informal discussions at > the workshop. The first Internet-Draft on LISP appeared in January, > 2007, along with a LISP mailing list at the IETF. [LISP] > > Trial implementations started at that time, with initial trial > deployments underway since June 2007; the results of early experience > have been fed back into the design in a continuous, ongoing process > over several years. LISP at this point represents a moderately > mature system, having undergone a long organic series of changes and > updates. > > LISP transitioned from an IRTF activity to an IETF WG in March 2009, > and after numerous revisions, the basic specifications moved to > becoming RFCs in 2012 (although work to expand and improve it > continues, and undoubtly will for a long time to come). > > 2. Deployment Philosophy > > It may seem odd to cover 'deployment philosophy' at this point in > such a document. However the deployment philosophy was a major > driver for much of the design (to some degree the architecture, and > to a very large measure, the engineering). So, as such an important > motivator, it is very desirable for readers to have this material in > hand as they examine the design, so that design choices that may seem > questionable at first glance can be better understood. > > Experience over the last several decades has shown that having a > viable 'deployment model' for a new design is absolutely key to the > success of that design. A new design may be fantastic - but if it > can not or will not be successfully deployed (for whatever factors), > it is useless. This absolute primacy of a viable deployment model is > what has lead to some painful compromises in the design. > > The extreme focus on a viable deployment scheme is one of the > novelties of LISP. There is an in-depth discussion about deployment scenarios in: http://tools.ietf.org/html/draft-ietf-lisp-deployment-05. I also suggest citing this draft. > 2.1. Economics > > The key factor in successful adoption, as shown by recent experience > in the Internet - and little appreciated to begin with, some decades > back - is economics: does the new design have benefits which outweigh > its costs. Typo?: missing ? > More importantly, this balance needs to hold for early adopters - > because if they do not receive benefits to their adoption, the sphere > of earliest adopters will not expand, and it will never get to > widespread deployment. One might have the world's best clean-slate > design, but if it does not have a deployment plan which is > economically feasible, it's just a mildly interesting piece of paper. > > This is particularly true of architectural enhancements, which are > far less likely to be an addition which one can 'bolt onto the side' > of existing mechanisms, and often offer their greatest benefits only > when widely (or ubiquitously) deployed. > > Maximizing the cost-benefit ratio obviously has two aspects. First, > on the cost side, by making the design as inexpensive as possible, > which means in part making the deployment as easy as possible. > Second, on the benefit side, by providing many new capabilities, > which is best done not by loading the design up with lots of features > or options (which adds complexity), but by making the addition > powerful through deeper flexibility. We believe LISP has met both of > these goals. Related paper: http://www.cs.princeton.edu/~jrex/papers/cacm10.pdf. I am not suggesting citing it, but rather consider its main argument. > 2.2. Maximize Re-use of Existing Mechanism > > One key part of reducing the cost of a new design is to absolutely > minimize the amount of change _required_ to existing, deployed, > devices: the fewer devices need to be changed, and the smaller the > change to those that do, the lower the pain (and thus the greater the > likelihood) of deployment. > > Designs which absolutely require 'forklift upgrades' to large amounts > of existing gear are far less likely to succeed - because they have > to have extremely large benefits to make their very substantial costs > worthwhile. > > It is for this reason that LISP, in most cases, initially requires no > changes to devices in the Internet (both hosts and routers), and also > initially reuses, whereever possible, existing protocols (IPv4 > [RFC791] and IPv6 [RFC2460]). The 'initially' must be stressed - > careful attention has also long been paid to the long-term future > (see [Future]), and larger changes become feasible as deployment > succeeds. I think that I am not understanding this section, LISP does requires changes to some routers (a software update). > 2.3. Self-Deployment > > LISP has deliberately employed a rather different deployment model, > which we might call 'self-deployment'; it does not require a huge > push to get it deployed, rather, it is hoped that once people see it > and realize they can easily make good use of it _on their own_ (i.e. > without requiring adoption by others), it will 'deploy itself' (hence > the name of the approach). > > One can liken the problem of deploying new systems in this way to > rolling a snowball down a hill: unless one starts with a big enough > initial snowball, and finds a hill of the right steepness (i.e. the > right path for it to travel, once it starts moving), one's snowball > is not going to go anywhere on its own. However, if one has picked > one's spot correctly, little additional work is needed - just stand > back and watch it go. The benefits of the above-mentioned "self-deployment" can be summarised as the interoperability with existing infrastructure. As a result LISP provides some benefits to early adopters while retaining full compatibility with the legacy infrastructure. > 3. LISP Overview > > LISP is an incrementally deployable architectural upgrade to the > existing Internet infrastructure, one which provides separation of > location and identity. The separation is usually not perfect, for > reasons which are driven by the deployment philosophy (above), and > explored in a little more detail elsewhere (in [Architecture], > Section "Namespaces-EIDs-Residual"). > > LISP separates the functions of location and identity, current > intermingled in IPvN addresses. (This document uses the meaning for > 'address' proposed in [Atkinson], i.e. a name with mixed location and > identity semantics.) > > 3.1. Basic Approach > > In LISP, nodes have both a 'locator' (a name which says _where_ in > the network's connectivity structure the node is), called an 'RLOC', > and an 'identifier' (a name which serves only to provide a persistent > handle for the node), called an 'EID'. A node may have more than one > RLOC, or its RLOC may change over time (e.g. if the node is mobile), > but it keeps the same EID. Suggested rewording: "RLOC, *and* its RLOC*(s) may change…" > Technically, one should probably say that ideally, the EID names the > node (or rather, its end-end communication stack, if one wants to be > as forward-looking as possible), and the RLOC(s) name interface(s). > (At the moment, in reality, the situation is somewhat more complex, > as will be explained elsewhere (in [Architecture], Section > "Namespaces-EIDs-Residual"). > > This second distinction, of _what_ is named by the two classes of > name, is necessary both to enable some of the capabilities that LISP > provides (e.g the ability to seamlessly support multiple interfaces, > to different networks), and is also a further enhancement to the > architecture. Faailing to clearly recognize both interfaces and > communication stacks as distinctly separate classes of things is > another failing of the existing Internet architecture (again, one > inherited from the previous generation of networking). Typo: Faailing > A novelty in LISP is that it uses existing IPvN addresses (initially, > at least) for both of these kinds of names, thereby minimizing the > deployment cost, as well as providing the ability to easily interact > with unmodified hosts and routers. > > 3.2. Basic Functionality > > The basic operation of LISP, as it currently stands, is that LISP > augmented packet switches near the source and destination of packets > intercept traffic, and 'enhance' the packets. > > The LISP device near the source looks up additional information about > the destination, and then wraps the packet in an outer header, one > which contains some of that additional information. The LISP device > near the destination removes that header, leaving the original, > unmodified, packet to be processed by the destination node. > > The LISP device near the source (the Ingress Tunnel Router, or 'ITR') > uses the information originally in the packet about the identity of > its ultimate destination, i.e. the destination address, which one can > view as the EID of the ultimate destination. It uses the destination > EID to look up the current location (the RLOC) of that EID. > > The lookup is performed through a 'mapping system', which is the > heart of LISP: it is a distributed directory of bindings from EIDs to > RLOCS. The destination RLOC will be (initially at least) the address > of the LISP device near the destination (the Egress Tunnel Router, or > 'ETR'). > > The ITR then generates a new outer header for the original packet, > with that header containing the destination's RLOC as the wrapped > packet's destination, and the ITR's own address (i.e. the RLOC of the > original source) as the wrapped packet's source, and sends it off. > > When the packet gets to the ETR, that outer header is stripped off, > and the original packet is forwarded to the original ultimate > destination for normal processing. > > Return traffic is handled similarly, often (depending on the > network's configuration) with the original ITR and ETR switching > roles. The ETR and ITR functionality is usually co-located in a > single device; these are normally denominated as 'xTRs'. In this section the Mapping System is defined as directory, in the section below as a database. I suggest using a consistent notation. > 3.3. Mapping from EIDs to RLOCs > > The mappings from EIDs to RLOCs are provided by a distributed (and > potentially replicated) database, the mapping database, which is the > heart of LISP. > > Mappings are requested on need, not (generally) pre-loaded; in other > words, mapping are distributed via a 'pull' mechanism. Once obtained > by an ITR, they are cached, to limit the amount of control traffic to > a practicable level. (The mapping system will be discussed in more > detail below, in Section 5.2 and Section 9) > > Extensive studies, including large-scale simulations driven by > lengthy recordings of actual traffic at several major sites, have > been performed to verify that this 'pull and cache' approach is > viable, in practical engineering terms. [Iannone] (This subject will > be discussed in more detail in Section 9.5, below.) Related paper: http://ebookbrowse.com/an-analytical-model-for-the-lisp-cache-size-pdf-d362171631 This work presents an general analythical model that relates the hit-rate, cache size vs. parameters describing the traffic and show the feasability of lisp under some circumstances. > > 3.4. Interworking With Non-LISP-Capable Endpoints > > The capability for 'easy' interoperation between nodes using LISP, > and existing non-LISP-using hosts or sites (often called 'legacy' > hosts), is clearly crucial. > > To allow such interoperation, a number of mechanisms have been > designed. This multiplicity is in part because different mechanisms > have different advantages and disadvantages (so that no single > mechanism is optimal for all cases), but also because with limited > field experience, it is not clear which (if any) approach will be > preferable. > > One approach uses proxy LISP devices, called PITRs (proxy ITRs) and > PETRs (proxy ETRs), to provide LISP functionality during interaction > with legacy sites. Another approach uses a device with combined LISP > and NAT ([RFC1631]) functionality, named a LISP-NAT. I don´t see why LISP-NAT is mentioned here, LISP-NAT is not related with interoperating with non-lisp capable endpoints. Could you please clarify? [snip] > 4.3. Traffic Engineering > > 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 visualized when the Internet was designed, so support for it > is somewhat in the 'when the only tool you have is a hammer, > everything looks like nail' category. > > 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 computationa), 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 binding 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 binding > layer to provide TE, the overhead is limited to those who are > actually communicating with that particular destination. Why *poor*? Id/Loc binding is an efficient way to provide TE, and LISP is a good example. Actually in section 9.4 it is defined as a "powerful" way to provide such feature. > LISP includes a number of features in the mapping system to support > TE. (Described in Section 5.2 below.) > 4.4. Mobility > > Mobility is yet another place where separation of location and > identity is obviously a key part of a clean, efficient and high- > functionality solution. Considerable experimentation has been > completed on doing mobility with LISP. > > 4.5. IP Version Reciprocal Traversal > > Note that LISP 'automagically' allows 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 > would allow an 'island' of operation of one type to be > 'automatically' tunneled over a stretch of infrastucture which only > supports the other type. > > While the machinery of LISP may seem too heavyweight to be good for > such a mundane use, this is not intended as a 'sole use' case for > deployment of LISP. Rather, it is something which, if LISP is being > deployed anyway (for its other advantages), is an added benefit that > one gets 'for free'. > > 4.6. Local Uses > > LISP has a number of use cases which are within purely 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, IP version traversal, and support > of VPN's for segmentation and multi-tenancy (i.e. a spatially > separated private VPN whose components are joined together using the > public Internet as a backbone). > > Among the latter class, non-Internet applications which have no > analog on the Internet, are the following example applications: > virtual machine mobility in data centers; other non-IP EID types such > as local network MAC addresses, or application specific data. > > 5. Major Functional Subsystems > > LISP has only two major functional subsystems - the collection of > LISP packet switches (the xTRs), and the mapping system, which > manages the mapping database. The purpose and operation of each is > described at a high level below, and then, later on, in a fair amount > of detail, in separate sections on each (Sections Section 8 and > Section 9, respectively). I suggest routers instead of switches given that xTRs operate at L3. [snip] > 8. xTRs > > As mentioned above (in Section 5.1), xTRs are the basic data-handling > devices in LISP. This section explores some advanced topics related > to xTRs. > > Careful rules have been specified for both TTL and ECN [RFC3168] to > ensure that passage through xTRs does not interfere with the > operation of these mechanisms. In addition, care has been taken to > ensure that 'traceroute' works when xTRs are involved. Could you provide arguments supporting such claim (last paragraph)? AFAIK traceroute does not actually work in LISP given that it sees the RLOC space as a single hop. > 8.1. When to Encapsulate > > An ITR knows that a destination is running LISP, and thus that it > should perform LISP processing on a packet (including potential > encapsulation) if it has an entry in its local mapping cache that > covers the destination EID. > > Conversely, if the cache contains a 'negative' entry (indicating that > the ITR has previously attempted to find a mapping that covers this > EID, and it has been informed by the mapping system that no such > mapping exists), it knows the destination is not running LISP, and > the packet can be forwarded normally. > > (The ITR cannot simply depend on the appearance, or non-appearance, > of the destination in the DFZ routing tables, as a way to tell if a > destination is a LISP site or not, because mechanisms to allow > interoperation of LISP sites and 'legacy' sites necessarily involve > advertising LISP sites' EIDs into the DFZ.) This scenario is defined as LISP+BGP in the lisp deployment draft. > 8.2. UDP Encapsulation Details > > The UDP encapsulation used by LISP for carrying traffic from ITR to > ETR, and many of the details of how the it works, were all chosen for > very practical reasons. > > Use of UDP (instead of, say, a LISP-specific protocol number) was > driven by the fact that many devices filter out 'unknown' protocols, > so adopting a non-UDP encapsulation would have made the initial > deployment of LISP harder - and our goal (see Section 2.1) was to > make the deployment as easy as possible. > > The UDP source port in the encapsulated packet is a hash of the > original source and destination; this is because many ISPs use > multiple parallel paths (so-called 'Equal Cost Multi-Path'), and > load-share across them. Using such a hash in the source-port in the > outer header both allows LISP traffic to be load-shared, and also > ensures that packets from individual connections are delivered in > order (since most ISPs try to ensure that packets for a particular > {source, source port, destination, destination port} tuple flow along > a single path, and do not become disordered).. > > The UDP checksum is zero because the inner packet usually already has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > In most exising hardware, computing such a checksum (and checking it > at the other end) would also present an intolerable load, for no > benefit. Typo? end-to-end? > 8.5. Mapping Gleaning in ETRs > > As an optimization to the mapping acquisition process, ETRs are > allowed to 'glean' mappings from incoming user data packets, and also > from incoming Map-Request control messages. This is not secure, and > so any such mapping must be 'verified' by sending a Map-Request to > get an authoritative mapping. (See further discussion of the > security implications of this in [Architecture], Section "Security- > xTRs".) > > The value of gleaning is that most communications are two-way, and so > if host A is sending packets to host B (therefore needing B's > EID->RLOC mapping), very likely B will soon be sending packets back > to A (and thus needing A's EID->RLOC mapping). Without gleaning, > this would sometimes result in a delay, and the dropping of the first > return packet; this is felt to be very undesirable. IMO gleaning is not secure, this is well accepted by the WG and should be clearly discouraged. [snip] > 9.2.2. Map-Reply Maessages Typo: Messages [snip] > 10.1. Internetworking Mechanism > > One aspect which has received a lot of attention are the mechanisms > previously referred to (in Section 3.4) to allow interoperation of > LISP sites with so-called 'legacy' sites which are not running LISP > (yet). (yet)->This is a very strong statement, I suggest removing it. > To briefly refresh what was said there, there are two main approaches > to such interworking: proxy nodes (PITRs and PETRs), and an > alternative mechanism using device with combined NAT and LISP > functionality; these are described in more detail here. > > 10.2. Proxy Devices > > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. PETRs (proxy ETRs) serve as ETRs for LISP traffic > _to_ legacy hosts (for cases where a LISP device cannot send packets > directly to such sites, without encapsulation). > > Note that return traffic _to_ a legacy site from a LISP-using node > does not necessarily have to pass through an ITR/PETR pair - the > original packets can usually just be sent directly to the > destination. However, for some kinds of LISP operation (e.g. mobile > nodes), this is not possible; in these situations, the PETR is > needed. The main reason behind this is uPRF, I suggest mentioning it. > 10.2.1. PITRs > > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. To do that, they have to advertise into the > existing legacy backbone Internet routing the availability of > whatever ranges of EIDs (i.e. of nodes using LISP) they are proxying > for, so that legacy hosts will know where to send traffic to those > LISP nodes. > > As mentioned previously (Section 8.1), an ITR at another LISP site > can avoid using a PITR (i.e. it can detect that a given destination > is not a legacy site, if a PITR is advertising it into the DFZ) by > checking to see if a LISP mapping exists for that destination. > > This technique obviously has an impact on routing table in the DFZ, > but it is not clear yet exactly what that impact will be; it is very > dependent on the collected details of many individual deployment > decisions. > > A PITR may cover a group of EID blocks with a single EID > advertisement, in order to reduce the number of routing table entries > added. (In fact, at the moment, aggressive aggregation of EID > announcements is performed, precisely to to minimize the number of > new announced routes added by this technique.) > > At the same time, it a site does traffic engineering with LISP > instead of fine-grained BGP announcement, that will help keep table > sizes down (and this is true even in the early stages of LISP > deployment). The same is true for multi-homing. In the deployment draft we describe the Proxy-ITR Route Distribution (PITR-RD), I think it makes sense to mention it here. > > 10.2.2. PETRs > > PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy hosts, > for cases where a LISP device cannot send packets to sites without > encapsulation. That typically happens for one of two reasons. > > First, it will happen in places where some device is implementing > Unicast Reverse Path Forwarding (uRPF), to prevent a variety of > negative behaviour; originating packets with the source's EID in the > source address field will result in them being filtered out and > discarded. > > Second, it will happen when a LISP site wishes to send packets to a > non-LISP site, and the path in between does not support the > particular IP protocol version used by the source along its entir > length. Use of a PETR on the other side of the 'gap' will allow the > LISP site's packet to 'hop over' the gap, by utilizing LISP's > built-in support for mixed protocol encapsulation. > > PETRs are generally paired with specific ITRs, which have the > location of their PETRs configured into them. In other words, unlike > normal ETRS, PETRs do not have to register themselves in the mapping > database, on behalf of any legacy sites they serve. > > Also, allowing an ITR to always send traffic leaving a site to a PETR > does avoid having to chose whether or not to encapsulate packets; it > can just always encapsulate packets, sending them to the PETR if it > has no specific mapping for the destination. However, this is not > advised: as mentioned, it is easy to tell if something is a legacy > destination. PETR can be used also to forward packets that miss in the map-cache, this avoids drops/buffering and improves the overall performance. It is also very easy to implement. > 10.3. LISP-NAT > > A LISP-NAT device, as previously mentioned, combines LISP and NAT > functionality, in order to allow a LISP site which is internally > using addresses which cannot be globally routed to communicate with > non-LISP sites elsewhere in the Internet. (In other words, the > technique used by the PITR approach simply cannot be used in this > case.) > > To do this, a LISP-NAT performs the usual NAT functionality, and > translates a host's source address(es) in packets passing through it > from an 'inner' value to an 'outer' value, and storing that > translation in a table, which it can use to similarly process > subsequent packets (both outgoing and incoming). [Interworking] > > There are two main cases where this might apply: > - Sites using non-routable global addresses > - Sites using private addresses [RFC1918] > > 10.4. LISP and DFZ Routing > > {{To be written.}} > > 10.5. Use Through NAT Devices > > Like them or not (and NAT devices have many egregious issues - some > inherent in the nature of the process of mapping addresses; others, > such as the brittleness due to non-replicated critical state, caused > by the way NATs were introduced, as stand-alone 'invisible' boxes), > NATs are both ubiquitous, and here to stay for a long time to come. > > Thus, in the actual Internet of today, having any new mechanisms > function well in the presence of NATs (i.e. with LISP xTRs behind a > NAT device) is absolutely necessary. LISP has produced a variety of > mechanisms to do this. > > 10.5.1. First-Phase NAT Support > > The first mechanism used by LISP to operate through a NAT device only > worked with some NATs, those which were configurable to allow inbound > packet traffic to reach a configured host. > > A pair of new LISP control messages, LISP Echo-Request and Echo- > Reply, allowed the ETR to discover its temporary global address; the > Echo-Request was sent to the configured Map-Server, and it replied > with an Echo-Reply which included the source address from which the > Echo Request was received (i.e. the public global address assigned to > the ETR by the NAT). The ETR could then insert that address in any > Map-Reply control messages which it sent to correspondent ITRs. > > The fact that this mechanism did not support all NATs, and also > required manual configuration of the NAT, meant that this was not a > good solution; in addition, since LISP expects all incoming data > traffic to be on a specific port, it was not possible to have > multiple ETRs behind a single NAT (which normally would have only one > global address to share, meaning port mapping would have to be used, > except that... ) IMHO this provides too much details to the reader. This is the only LISP feature that is presented along with its history. [snip] > 11.2. Replacement of ALT with DDT > > As mentioned in Section 9.2, an interface is provided to allow > replacement of the indexing subsystem. LISP initially used an > indexing system called ALT. [ALT] ALT was relatively easy to > construct from existing tools (GRE, BGP, etc), but it had a number of > issues that made it unsuitable for large-scale use. ALT is now being > superseded by DDT. > > As indicated previously (Section 9.5), the basic structure and > operation of DDT is identical to that of TREE, so the extensive > simulation work done for TREE applies equally to DDT, as do the > conclusions drawn about TREE's superiority to ALT. [Jakab] > > {{Briefly synopsize results}} If needed, I volunteer to write a short summary of the main results. > > 11.2.1. Why Not Use DNS > > One obvious question is 'Since DDT is so similar to DNS, why not > simply use DNS?' In particular, people are familiar with the DNS, > how to configure it, etc - would it not thus be preferable to use it? > To completely answer this would take more space that available here, > but, briefly, there were two main reasons, and one lesser one. > > First, the syntax of DNS names did not lend itself to looking up > names in other syntaxes (e.g. bit fields). This is a problem which > has been previously encountered, e.g. in reverse address lookups. > [RFC5855] > > Second, as an existing system, the interfaces between DNS (should it > have been used as an indexing subsystem for LISP) would not be > 'tuneable' to be optimal for LISP. For instance, if it were desired > to have the leaf node in an indexing lookup directly contact the ETR > on behalf of the node doing the lookup (thereby avoiding a round-trip > delay), that would not be easy without modifications to the DNS code. > Obviously, with a 'custom' system, this issue does not arise. > > Finally, DNS security, while robust, is fairly complex. Doing DDT > offered an opportunity to provide a more nuanced security model. > (See [Architecture], Section "Security" for more about this.) Last paragraph->This is a strong statement presented without the appropriate arguments. I don´t see why DDT security (not discussed in detail) is less complex that DNS-SEC. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
