Sun: Thanks for the comments/questions. With your permission, I am posting them and my responses to the RRG list. Please see my responses inline below. I hope they are helpful.
Sriram >From: Charrie Sun [charrie...@gmail.com] >Sent: Wednesday, December 23, 2009 11:27 PM >To: Sriram, Kotikalapudi >Subject: Questions about Enhanced Efficiency of Mapping Distribution Protocols > >Hi Sriram, > I have recently read your proposal of "Enhanced Efficiency of >Mapping Distribution Protocols in Map-and-Encap Schemes" >for the scalable routing task. I raised some questions and want to >discuss with you. Since it includes some pictures in the >discussion I put them in the attachment. > > >1) The figure below which you showed in your presentation slide KS: For the benefit of people in this list, this is the figure in slide 20 of my presentation: http://www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf >Well why does the slope of Approach 2’s curve become flatter? >As each time a response sends only one relevant mapping >I thought the first-packet-delay wouldn’t change in the theoretical sense. >What matters more, I think, would be the average delay of all first-packet. >Say, comparing as to a common prefix, and this would compare >the first two approaches more explicitly. KS: This is a heuristic plot. Yes, I had the _average_ of first packet delay in mind. When the # of exceptions (x-axis) is quite small, in approach 2 the first packet may benefit from a cache at ILM-R (see slide 14), and when the # of exceptions goes higher, then most map requests will propagate to ILM resulting in higher delays. But you are right that the plot will be primarily flat then onwards. In approach 1, on the other hand, when the # of exceptions is higher, then the cache hit ratio will be perfect for “first” packets of subsequent sessions because the “first” packet of the very first session destined for that prefix has already fetched all of the maps (including all exceptions). But the first packet of the very first session destined for a prefix in consideration has to wait for many exception maps to be processed at the ILM-R and the ITR. Hence, the more rapidly increasing delay-plot for approach 1. I think you were OK with the plot for approach 1, but I thought I will try to elaborate on explanation for both delay-plots and try to put it all in perspective. Thanks for the question. >2) The second question arises when you talk about hierarchy of ETRs in >Slide 23. KS: Here you are referring to slide 23 / slide 24 in the presentation: http://www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf -- also same as Figure 3 (page 6) in the detailed document: http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf >Well I think it is in fact a matter of core’s routing system, and each ETR >should >advertise their directly-mapped EID prefixes. Though higher level ETRs can >aggregate mapping to alleviate the load of mapping distribution, this can >mix up mapping system with the routing system. However how to define >“core” and “edge” is still a hard problem :) KS: Your comment here is well taken. Yes, in general “ETR should advertise their directly-mapped EID prefixes” as you have stated. My thinking is that if lower-level ETRs (see Slides 23 and 24) DO indeed delegate to a higher-level ETR the aggregation and notification of mapping messages, then the higher-level ETR can suppress the fragments (deaggregates) while it announces a map for the covering aggregate EID. However, if a subnet is multi-homed to multiple ETRs (see slide 24 or Fig. 3 in the detailed document), then the subnet (deaggregate) gets announced by another higher-level ETR even thought the parent higher-level ETR has announced only the aggregate. In this situation, our proposal is to depref the deaggregated EID subprefix in the mapping distribution protocol by incorporating a “backup” indicator (see slide 24). A sending host will normally receive a response (to a map request) with information about the primary ETR (i.e., the aggregating ETR) as the locator for a prefix. The backup ETR will be used in a map response only in circumstances when primary ETR is known to be in a failure-recovery state or has otherwise withdrawn the aggregate. Finally, on your last point, yes, I am also somewhat troubled about definition of "core" and "edge" separation. Sriram _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
