I am forwarding some comments from Dino on the proposal that I submitted to RRG. I have his permission to post them to this list. Dino and I had a several follow up emails between us. I will try to summarize them later for this list. For now I am forwarding only his first email to me with his detailed comments.
The slides Dino is referring to are at: http://www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf Sriram ________________________________________ From: Dino Farinacci [d...@cisco.com] Sent: Monday, January 18, 2010 2:09 AM To: Sriram, Kotikalapudi Subject: Re: [rrg] Summary of "Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes" Sorry for the delay. Here are my comments on the MDP slides. I hope it is okay I copied by LISP colleagues on this reply. Thanks. Slide 6, the problem itself. Sriram, I am not even convinced this is going to be a real problem. I do not know why a registry would allocate a more-specific when it already allocated a less-specific to another site. You tell me why you think that would be useful. Slide 7. In LISP-ALT, the Map-Request would follow the /24 site and not the /20 since they would both be in the mapping system. That is assuming a Map-Request is sent for an EID that matches the /24. If a site requested an EID that matched the /20, then yes, the re- encapsulating path would occur. But the mapping system, could indicate there are more specifics to the /20. Slide 9. Yes, the nature solution is to have the coarser site tell you about the more specifics. But I like to couch the problem this way: if cisco had the /20, you think it would want to provide resources for the /24s that belong to Juniper? So, I am not sure how this could work in the real world. Slide 11. So one case we, the LISP team, were worried about is the sheer number of more-specifics. What if a companies mobile-node EIDs came out of their corporate EID-prefix. Then the number of EIDs could be in the 10s of thousands. So a scheme that returns all more specifics is probably not a good idea. In the LISP -06 spec we indicate this but are hoping that the MNs come out of their own EID-prefix allocation which is made up of only /32s. Slide 15. Approach 2 is better but still may be too many entries for an ILM- R to store. Slide 17. If the more-specifics have a common width, and it is communicated to the ITR from the ILMs, then the ITR could see that a different, say /24 is being encapsulated and then send the Map-Request for it even though there is a /20 cached. So rather than saying there are more specifics, indicate what the mask-lengths are. We could have more than one as long as a small number. For IPv4, that number is pretty small but not for IPv6. Slide 23, this is a good idea. And we believe LISP can support this as specified. Thanks and nice concise work, Dino > _______________________________________ > From: Sriram, Kotikalapudi > Sent: Tuesday, December 22, 2009 10:44 PM > To: Lixia Zhang; rrg@irtf.org > Cc: Tony Li > Subject: Summary of "Enhanced Efficiency of Mapping Distribution > Protocols in Map-and-Encap Schemes" > > Lixia: > Tony: > > As you would remember, I had presented this work at Dublin RRG > meeting. > I do not intend it to be a contribution for the mainstream set of > proposals > for a solution for scalability. Also, it relates in part to making > mapping distribution > more efficient -- I have followed some of the discussion about > relevance of including > "mapping systems" between you, Michael Menth, Biran and others. > Well, this is not a proposal for a new type of "mapping system" > but it is about making map-and-encap (LISP type of) schemes > more efficient by suitable enhancements to the mapping distribution > protocol. There is a part of this proposal which deals with > hierarchy of > locators (ETRs) for hierarchical map-and-encap schemes (there is > some possible > conceptual overlap with the GLI-Split proposal). > > My main intent in submitting this proposal/document is for archival > value. > As the RRG work moves further along, I would be happy if we can > revisit the ideas presented here. At that point, I would also plan > to further assist > with more details and performance modeling of this proposal. > > Sriram > > Summary (980 words) follows. > --------------------------------------------------------------------------------------------------------- > Summary of > "Enhanced Efficiency of Mapping Distribution Protocols in Map-and- > Encap Schemes" > > We present some architectural principles pertaining to the mapping > distribution protocols, especially applicable to map-and-encap > (e.g., LISP) type of protocols. These principles enhance the > efficiency of the map-and-encap protocols in terms of (1) better > utilization of resources (e.g., processing and memory) at Ingress > Tunnel Routers (ITRs) and mapping servers, and consequently, (2) > reduction of response time (e.g., first packet delay). We consider > how Egress Tunnel Routers (ETRs) can perform aggregation of end- > point ID (EID) address space belonging to their downstream delivery > networks, in spite of migration/re-homing of some subprefixes to > other ETRs. This aggregation may be useful for reducing the > processing load and memory consumption associated with map messages, > especially at some resource-constrained ITRs and subsystems of the > mapping distribution system. We also consider another architectural > concept where the ETRs are organized in a hierarchical manner for > the poten > tial benefit of aggregation of their EID address spaces. The two key > architectural ideas are discussed in some more detail below. A more > complete description can be found in a document that was presented > at the RRG meeting in Dublin. Links to the document and slides > presented at Dublin RRG meeting are: > Document: > http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf > Presentation slides: > http://www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf > > It will be helpful to refer to Figures 1, 2, and 3 in the document > noted above for some of the discussions that follow here below. > > A. Management of Mapping Distribution of Subprefixes Spread > Across Multiple ETRs > > To assist in this discussion, we start with the high level > architecture of a map-and-encap approach (it would be helpful to see > Fig. 1 in the document mentioned above). In this architecture we > have the usual ITRs, ETRs, delivery networks, etc. In addition, we > have the ID-Locator Mapping (ILM) servers which are repositories for > complete mapping information, while the ILM-Regional (ILM-R) servers > can contain partial and/or regionally relevant mapping information. > > While a large endpoint address space contained in a prefix may be > mostly associated with the delivery networks served by one ETR, some > fragments (subprefixes) of that address space may be located > elsewhere at other ETRs. Let a/20 denote a prefix that is > conceptually viewed as composed of 16 subnets of /24 size that are > denoted as a1/24, a2/24, :::, a16/24. For example, a/20 is mostly at > ETR1, while only two of its subprefixes a8/24 and a15/24 are > elsewhere at ETR3 and ETR2, respectively (see Fig. 2 in the > document). From the point of view of efficiency of the mapping > distribution protocol, it may be beneficial for ETR1 to announce a > map for the entire space a/20 (rather than fragment it into a > multitude of more-specific prefixes), and provide the necessary > exceptions in the map information. Thus the map message could be in > the form of Map:(a/20, ETR1; Exceptions: a8/24, a15/24). In > addition, ETR2 and ETR3 announce the maps for a15/24 and a8/24, > respectively, and so the ILMs k > now where the exception EID addresses are located. Now consider a > host associated with ITR1 initiating a packet destined for an > address a7(1), which is in a7/24 that is not in the exception > portion of a/20. Now a question arises as to which of the following > approaches would be the best choice: > > 1) ILM-R provides the complete mapping information for a/20 to ITR1 > including all maps for relevant exception subprefixes. > 2) ILM-R provides only the directly relevant map to ITR1 which in > this case is (a/20, ETR1). > > In the first approach, the advantage is that ITR1 would have the > complete mapping for a/20 (including exception subnets), and it > would not have to generate queries for subsequent first packets that > are destined to any address in a/20, including a8/24 and a15/24. > However, the disadvantage is that if there is a significant number > of exception subprefixes, then the very first packet destined for a/ > 20 will experience a long delay, and also the processors at ITR1 and > ILM-R can experience overload. In addition, the memory usage at ITR1 > can be very inefficient as well. The advantage of the second > approach above is that the ILM-R does not overload resources at ITR1 > both in terms of processing and memory usage but it needs an > enhanced map response in of the form Map:(a/20, ETR1, MS=1), where > MS (more specific) indicator is set to 1 to indicate to ITR1 that > not all subnets in a/20 map to ETR1. The key idea is that > aggregation is beneficial and subnet exceptions must be handled with > add > itional messages or indicators in the maps. > > B. Management of Mapping Distribution for Scenarios with Hierarchy > of ETRs and Multi-Homing > > Now we highlight another architectural concept related to mapping > management (helpful here to refer to Fig. 3 in the document). Here > we consider the possibility that ETRs may be organized in a > hierarchical manner. For instance ETR7 is higher in hierarchy > relative to ETR1, ETR2, and ETR3, and like-wise ETR8 is higher > relative to ETR4, ETR5, and ETR6. For instance, ETRs 1 through 3 can > relegate locator role to ETR7 for their EID address space. In > essence, they can allow ETR7 to act as the locator for the delivery > networks in their purview. ETR7 keeps a local mapping table for > mapping the appropriate EID address space to specific ETRs that are > hierarchically associated with it in the level below. In this > situation, ETR7 can perform EID address space aggregation across > ETRs 1 through 3 and can also include its own immediate EID address > space for the purpose of that aggregation. The many details related > to this approach and special circumstances involving multi-homing of > subnets a > re discussed in detail in the detailed document noted earlier. The > hierarchical organization of ETRs and delivery networks should help > in the future growth and scalability of ETRs and mapping > distribution networks. This is essentially recursive map-and-encap, > and some of the mapping distribution and management functionality > will remain local to topologically neighboring delivery networks > which are hierarchically underneath ETRs. _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
