Subject: Re: [rrg] Questions about Enhanced Efficiency of Mapping Distribution Protocols

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 30 Dec 2009 00:17:07 -0500

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-masked]]
>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

---

From: Charrie Sun <[email-masked]>
Date: Wed, 30 Dec 2009 15:10:50 +0800

2009/12/30 Sriram, Kotikalapudi <[email-masked]>

> 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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 30 Dec 2009 11:05:43 -0500

________________________________________
From: Charrie Sun [[email-masked]]
Sent: Wednesday, December 30, 2009 2:10 AM
To: Sriram, Kotikalapudi
Cc: [email-masked]
Subject: Re: Questions about Enhanced Efficiency of Mapping Distribution        Protocols

------------- snip --------------------------------

Follow up question from Charrie Sun:
Then this backup information can make the same storage and distribution 
cost as to the original non-aggregated mappings, right?

Response to the followup question:
KS: That is not the case. Only a small fraction of subnets are multi-homed to multiple 
ASs as you can see from slide 40 at link below (based on analysis performed at NIST).
http://www.antd.nist.gov/bgp_security/publications/ARIN_NetHandle_OriginAS_Analysis.pdf
Actually, in this slide many of the MOASs are due to _stale_ route registrations at the IRRs!
So the fraction we are talking about is really small.
This is because, in reality, most of the time a subnet is originated by a single AS
and it is the AS that is multi-homed to ASs of multiple upstream ISPs and not the subnet.
Similarly, I think it would be rare that a subnet (or subsubnet) would multi-home directly
to multiple ETRs. More often a serving ETR at lower-level would multi-home to multiple
ETRs at higher-level in the hierarchy. The main savings in the proposal
is due to efficient handling of deaggregates that reside at another ETR
away from the ETR where bulk of the aggregated prefix resides.

Sriram

---

From: Charrie Sun <[email-masked]>
Date: Thu, 31 Dec 2009 11:14:51 +0800

2009/12/31 Sriram, Kotikalapudi [email-masked]

> Here I'm confused about the separation granularity. Isn't the separation to
separate stub AS from the core, but rather to separate subnets from their
ASes? As there are often one AS for each subnet, what's the use we do so?
The same question applies to ETRs.

Letong