> Continuing with my review. Many of the observations below are questions. I > may understand most of these better once I finish the whole document, but I > wanted to send out my notes already now.
Thanks for getting something out sooner rather than latter. See my comments inline. > Technical: > >> o End-systems (hosts) only send to addresses which are EIDs. They >> don't know addresses are EIDs versus RLOCs but assume packets get >> to LISP routers, which in turn, deliver packets to the destination >> the end-system has specified. >> > > Is this always true, e.g, when some interworking mechanism between the LISP > and non-LISP parts of the Internet is in use, and one of the peers employs > some NAT traversal techniques? It would seem that there can be cases where > the peers observe RLOC addresses and use them for some purpose. But they don't know they are RLOC addresses. All end-systems assume is that addresses they put int destination address fields will make it to the destination. So if the address is an RLOC, the underlying routing system will have routes to get the packet to the destination. Otherwise, the packet moves toward a LISP router that will encapsulate to get the packet to the destination. > This might be something to mention in the limitations/things to test section, > for instance, or discussed in in the interworking document (and maybe it > already is, I did not check). We mentionn nothing because the host doesn't care and doesn't need to care. >> A server host can be the endpoint >> of a LISP tunnel as well. > ... >> o RLOCs are always IP addresses assigned to routers >> > > Isn't this an inconsistency? Or is a server that terminates a tunnel called a > router? For the sake of this document and keeping it within the charter of the working group, a router is a LISP router. We do not consider hosts doing LISP as specified in the LISP-MN document. Which is out of charter for this working group. So if a server is acting as a router, then it has RLOCs. Hosts have EIDs assigned to them (when they are resident in a LISP site), IGP routers have EIDs assigned to them, and LISP routers have both EIDs and RLOCs assigned to them. >> o When a router originates packets it may use as a source address >> either an EID or RLOC. > > You should state somewhere what the manageability requirements are for making > this happen, or if hardcoded policies are sufficient (e.g., iBGP vs. eBGP use > of addresses). Does this require additional functionality for RFC 3484 style > source address selection, or can you cope with existing functionality? It does not. The same requirements for originating IP packets has not changed. If it is stated that the outgoing interface's address is used as the source address, then whatever namespace the address belongs to is used. > Note: I'm not asking for any new functionality, just a statement about the > expectations. No expectations. ;-) >> In order to avoid excessive packet overhead as well as possible >> encapsulation loops, this document mandates that a maximum of two >> LISP headers can be prepended to a packet. > > This seems hard to mandate in any real sense. Perhaps you want to say > "recommends" instead of "mandates"? We thought long and hard about this and wanted to mandate to indicate the seriousness of not going overboard with encapsulation. Now I know implementors can ignore specs, but for the record when it is documented the way we did it is more clear on the strength of the statement. >> 2. The LISP ITR must be able to map the EID destination to an RLOC >> of one of the ETRs at the destination site. The specific method >> used to do this is not described in this example. See [ALT >> <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-ALT>] or >> [CONS <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-CONS>] for >> possible solutions. >> >> 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be >> rate-limited. >> >> 4. When an alternate mapping system is not in use, the Map-Request >> packet is routed through the underlying routing system. >> Otherwise, the Map-Request packet is routed on an alternate >> logical topology. In either case, when the Map-Request arrives >> at one of the ETRs at the destination site, it will process the >> packet as a control message. > > First, the the "alternate mapping system" appears here for the first time. > Maybe you should indicate it refers to [ALT]. But we have a long list of mapping systems, do you want all of them to be listed? > Second, parts of step 4 go pretty deep in what the specific mapping methods > are. I'm wondering if this alternative text would fit better: > > "4. The Map-Request packet is delivered to the right ETR with the help of > the mapping system. (For instance, in [ALT] this happens via an EID-based > alternate routing topology.) In any case, when the Map-Request arrives …" Well it does not capture the fact that the Map-Request can be delivered via the underlying routing system. I will add a refernece to ALT though from your first comment. >> 6. The ITR receives the Map-Reply message, parses the message (to >> check for format validity) and stores the mapping information >> from the packet. This information is stored in the ITR's EID-to- >> RLOC mapping cache. Note that the map cache is an on-demand >> cache. An ITR will manage its map cache in such a way that >> optimizes for its resource constraints. >> > > This is just a comment, but FWIW, I am not super happy about the way the > caching is an integral part of the specifications for LISP. Fundamentally, > you could have used two orthogonal tools for dealing with routing > scalability: 1. have only a subset of routers have to deal with EID routing > (the xTRs) and 2. Which is the way LISP is designed. > use caching for scaling these routers better. If we had done this, then we > would have had a very easy Which is also the way LISP is designed. So I am not following you. > answer to those who have criticized the caching approach over the years: it > is optional and up to the implementors to use or not. The first tool would > still have been a valid approach to make the Internet scale better, even if > you never did any caching. The map-cache is only in the ITRs and PITRs as you described in point 1. And with added stretch the ITRs and PITRs could have a default cache entry that encapsulates to a set of ETRs which can hold more cache entries, and so on. If one chose to deploy LISP in a hierarchical way. > In any case, your description of the thins-to-test should probably say > something about effects of caching. We have added a lot of text to cover many concerns. After reading the entire document, let us know what you think. ;-) >> 8. The ETR receives these packets directly (since the destination >> address is one of its assigned IP addresses), strips the LISP >> header and forwards the packets to the attached destination host. >> >> Spoofing of inner header addresses of LISP encapsulated packets is >> possible like with any tunneling mechanism. ITRs MUST verify the >> source address of a packet to be an EID that belongs to the site's >> EID-prefix range prior to encapsulation. An ETR must only >> decapsulate and forward datagrams with an inner header destination >> that matches one of its EID-prefix ranges. If, upon receipt and >> decapsulation, the destination EID of a datagram does not match one >> of the ETR's configured EID-prefixes, the ETR MUST drop the >> datragram. If a LISP encapsulated packet arrives at an ETR, it MAY >> compare the inner header source EID address and the outer header >> source RLOC address with the mapping that exists in the mapping >> database. Then when spoofing attacks occur, the outer header source >> RLOC address can be used to trace back the attack to the source site, >> using existing operational tools. > > First, I think Step 8 should be slightly edited to cover the fact that some > additional checks are being made. E.g., "The ETR receives these packets > directly (since ...), checks the validity of the addresses used in the > packet, strips the LISP header and …" I will add "checks the validity of the addresses" and of course keep the text that follows Step 8. > Second, I wish you would have specified the source address checks better. Are > there situations where you would NOT want to make a pretty strict test, i.e., > that source EID maps to source RLOC? Because this is work still in progress. >> The next sub-sections illustrate packet formats for the >> homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 >> combinations SHOULD be supported. > > For interoperability, wouldn't it be cleaner to have a MUST here? How would I > otherwise know if I can send an IPv4-in-IPv6 packet to a destination? I can change to MUST. > Editorial: > >> Since additional tunnel headers are prepended, the packet becomes >> larger and can exceed the MTU of any link traversed from the ITR to >> the ETR. It is recommended in IPv4 that packets do not get >> fragmented as they are encapsulated by the ITR. Instead, the packet >> is dropped and an ICMP Too Big message is returned to the source. >> > > This feels odd, as there is no explanation in this point about what you do > with IPv6. Maybe a sentence on IPv6 should be added? It is explained in the MTU section. I think you may have not gotten there yet? > I'm sure the details on IPv6 follow later in the document, but I suspect that > other readers would be wondering here in the same way as I am. Yes, they do. > I'm reading on… Thanks. Dino > > Jari > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
