Hello everyone, Here's part II, with comments on sections 4-6.
General comments: - I'd consider moving some of the "other attempts failed to recognise X.." bits into their own section, or possibly into another document. I think these somewhat fall into the category of "LISP in the context of the history of the internet" :) - After reading more of this document, I think it starts to sound more like "A survey on LISP"? I hope my comments don't come across as overly negative.. 4. 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 [Perspective], Section "Namespaces-EIDs-Residual"). The first bit is probably OK, the second one I think doesn't add much value here, apart from saying that "if you want to look at some imperfections, go here". I'd move it into a later section if you need to discuss it at all. LISP separates the functions of location and identity of nodes (a nebulous term, deliberately chosen for use in this document precisely because its definition is not fixed - you will not go far wrong if you think of a node as being something like a host), which are currently intermingled in IPvN addresses. (This document uses the meaning for 'address' proposed in [Atkinson], i.e. a name with mixed location and identity semantics.) So in RFC6115 nodes were defined as either routers or hosts (section 1.2, 1.). What else are you thinking about? I think the bracketed bit just confuses readers, and I think it can be removed. I'm not sure whether location and identity are 'functions' of IPvN addresses, rather than, say, properties. Are you saying that the location is a function that takes as input an IP address and produces as output.. a location description? I guess you could look at it in that way. Again, I don't think that the 'intermingled' is very clear here. I also think that this paragraph is a bit repetitive; the separation is already identified in the preceding paragraph, and apart from the definition of address I don't think it adds much. 4.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' (short for 'routing locator'), and an 'identifier' (a name which serves only to provide a persistent handle for the node), called an 'EID' (short for 'endpoint identifier'). Style comment: I think it's better to spell acronyms out the first time they're being used, and then provide the abbreviation in brackets. A node may have more than one RLOC, or its RLOC may change over time (e.g. if the node is mobile), but it would normally always keep the same EID. A node may also have more than 1 EID, e.g. one for v4 and one (or more) for v6. Maybe it's worthwhile saying "EID(s)", or is that confusing? 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 [Perspective<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-Perspective>], Section "Namespaces-EIDs-Residual".) I think both of the sentences in brackets are confusing, and don't aid the reader much. The RLOCs naming the interfaces applies only to a small subset of devices in the LISP EID (address) space, namely the (P)xTRs, for the hosts in a LISP site the RLOCs name their xTRs' interfaces. 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). I think it would be better to talk about use-cases later in the document (I'm referring to the seamless multihoming). typo: Faailing => Failing I'm sure you guys know more about this, but I don't think that interfaces and communication stacks are completely separate "classes of things" (the word "things" would also bother me a little in standards documents, but I'm sure you know more about the expected style than I do). After all, L2 is a part of the communication stack, and that's to some degree bound to interfaces. 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. Good - not sure 'novelty' is the right word though. Maybe say something like.. "In order to minimise deployment costs, LISP supports existing IPvN addresses for both of these kinds of names, as well as other future address family types. The former facilitates the interaction with unmodified hosts and routers." 4.2 The first few paragraphs of this section take the reader from the abstract concept of 'intercepting' and 'augmenting' packets to the actual encapsulation process in multiple stages. I think this makes the whole process sound more mysterious than it actually is, but it's probably OK. The LISP device near the original 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 in LISP is the EID of the ultimate destination. It uses the destination EID to look up the current location (the RLOC) of that EID. I'd try and simplify the sentence a little bit, the destination bit is quite repetitive. Something like: The LISP device near the original source (…) extracts the destination address from the packet, which in this context is an Endpoint ID. It then looks up the current location of this destination EID. The lookup is performed through a 'mapping system', which is the heart of LISP: it is a distributed directory of mappings from EIDs to RLOCS. The destination RLOC will be (initially at least) the address of the LISP device near the ultimate destination (the Egress Tunnel Router, or 'ETR'). This is inconsistent with what 4.1 says about what RLOCs should ideally be. {{Is it worth distinguishing between 'mapping' and 'binding'? Should the document pick one term, and stick with it?}} To be honest, I'm not sure what the difference is. I looked at RFC6830, and it only uses the word binding in 2 places, the more useful one of which is this: "A map request for any endpoint will return a binding for the entire mobile prefix" (the other is in the context of mobile IP).. just a few sentences above that reference, it discusses the "validity of an EID-to-RLOC mapping for a longer time". The word 'mapping' occurs 173 times.. I'd prefer to know the difference between the two before giving an opinion, but my inclination would be to aim for consistency with the other RFCs. 4.3 I think it would be better to stick with 'mapping system', which was used in the previous paragraph, rather than using the term 'mapping database'. 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 by the ITR, to limit the amount of control traffic to a practicable level. (The mapping system will be discussed in more detail below, in Section 6.2<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#section-6.2> and Section 10<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#section-10>) I'd change 'on need' to 'on demand', and maybe state that the caching is also done for performance reasons (you don't want to drop every other packet). 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. (This subject will be discussed in more detail in Section 6.1.1<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#section-6.1.1>, below.) This is interesting. I'm not sure if I'd put it into a "further reading" section though. 4.4 I probably would've summarised the first two paragraphs into a sentence and merged it with the last one: In order to facilitate incremental LISP deployments, several mechanisms have been designed to allow LISP enabled nodes to communicate with non-LISP enabled (legacy) nodes, each with different trade-offs. One mechanism uses proxy LISP devices, called PITRs (proxy ITRs) and PETRs (proxy ETRs), to provide LISP functionality during interaction with legacy hosts. Another approach uses a device with combined LISP and NAT ([RFC1631]) functionality, named a LISP-NAT. But that's probably just me :) I would also provide references to the two approaches you introduced here. 4.5 I would provide the brief overview first, and then say "for more details, go to.." At the same time, I don't think that this section actually says anything at all about LISP security, beyond telling the reader that it's been considered, and that there's a tradeoff between security and deployability. It only talks about security in general. I would either remove this section, or replace it with one that actually provides a brief overview of /LISP/ security. [Vasilis already mentioned this] 5. I think the whole section focuses a little too much on the motivation to cater for the various use-cases, and a too little on how LISP uniquely addresses them.. But I get the impression that this is on purpose, and perhaps I just would've decided differently. 5.1 The referenced RFC appears to use the term "Provider-Aggregatable" In theory, it ought to be possible to update the DNS entries, and have everyone switch to the new addresses, but in practise, addresses are embedded in many places, such as firewall configurations at other sites. I think the point made here is valid, but not a difference between theory and practise in the way it's stated (in practise it's also possible to update DNS entries). You could say "In theory, it ought to be sufficient to update the DNS entries". 5.2 I think it'd be nice if this section explained at least briefly how LISP actually helps with multi homing (priority & weights). 5.3 I think the first two sections are somewhat repetitive in terms of explaining that the internet was not designed with TE in mind. I actually went and looked in section 6.2. The only bit that refers to TE is this: The mapping contains not just the RLOC(s), but also (for each RLOC for any given EID) priority and weight (to allow allocation of load between several RLOCs at a given priority); this allows a certain amount of traffic engineering to be accomplished with LISP. If it's just this one sentence, maybe it's worth stating that the priorities and weights can be used for [ingress] TE? 5.5 See 5, but I appreciate that mobility is somewhat outside of the charter. 5.6 "Note that LISP 'automagically' allows intermixing of various IP versions for packet carriage" => Are words like 'automagically' often used in RFCs? I would somehow tie in that this is because LISP can use different versions of IP (or other protocols?) for the EID and RLOC space, or is that too technical? 5.7 Is it worth mentioning the words 'network virtualisation' in this context, or is that too buzzwordy? 6.1 xTRs are fairly normal packet switches, enhanced with a little extra functionality in both the data and control planes, to perform LISP data and control functionality. I'd probably remove the "fairly normal" and "little extra".. Maybe something like "xTRs are packet switches, which support the LISP control protocol and LISP encapsulation in the switchpath", or something like that? I'd use the term 'decapsulate' for the ETR bit, since you used 'encapsulate' in the ITR paragraph. 6.1.1 I think this section is more appropriate for a survey than for an introduction. 6.2 I think it would be better to use the terms 'mapping system' and mapping database' consistently. The mapping system also contains attributes of RLOCs, namely the priority and weight. > However, the block may be (and often is) as small as a single EID. I'm not sure if "often" is correct. I took the HTML of http://www.lisp4.net/lisp-site/, discarded everything outside the main table, and all lines that didn't contain a '/' (trying to keep all the prefixes), sorted them and removed duplicates. That left me with 690 prefixes, 141 (~20%) of which were /32 or /128 (I didn't find /32 IPv6 addresses). I think the numbers make sense for an estimated nr of 355 sites, as it's on average ~2 prefixes/site. A particular node may have more than one RLOC, or may change its RLOC(s), while keeping its singlar identity. I'd remove singular, as sites may have more than one EID (as seen in the beta network example above). 6.2.2 Re: (MSs - admittedly a poorly chosen term, since their primary function is not to respond to queries, but it's too late to change it now). I'd be half inclined to remove the note about it being a poorly chosen term - maybe some day enabling proxy replies will be the recommended deployment method? -- Best regards, Michiel On 26 Jul 2013, at 21:35, Noel Chiappa <[email protected]<mailto:[email protected]>> wrote: From: [email protected]<mailto:[email protected]> (Noel Chiappa) Now that I think about it, the way to hopefully help (I'm not sure I'd say 'fix totally' ... ) is to add one sentence to the end of the abstract, saying as concisely as possible that a subset of the document, readable as a separate unit, forms a 'brief intoduction to LISP', and is considerably shorter than the document as a whole. ... All, does this sound like a good thing to do? Not having heard any disagreement, I will do this. (I'm not sure it will make Michiel totally happy, but if the abstract clearly says the document includes a stand-alone brief intro, there's not much more I can do if people ignore that.. :-) Noel _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
