2009/12/30 Sriram, Kotikalapudi <[email protected]> > 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 [[email protected]] > >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).
Then this backup information can make the same storage and distribution cost as to the original non-aggregated mappings, right? > 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 [email protected] http://www.irtf.org/mailman/listinfo/rrg
