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

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Wed, 30 December 2009 16:06 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A488B3A6A36 for <rrg@core3.amsl.com>; Wed, 30 Dec 2009 08:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fFmvlKbKfmR for <rrg@core3.amsl.com>; Wed, 30 Dec 2009 08:06:22 -0800 (PST)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 5EE173A693E for <rrg@irtf.org>; Wed, 30 Dec 2009 08:06:22 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nBUG5qRe022670; Wed, 30 Dec 2009 11:05:52 -0500
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Wed, 30 Dec 2009 11:05:52 -0500
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Charrie Sun <charriesun@gmail.com>
Date: Wed, 30 Dec 2009 11:05:43 -0500
Thread-Topic: Questions about Enhanced Efficiency of Mapping Distribution Protocols
Thread-Index: AcqJH0s10firniRCTyq9zujse1upGQARi/E0
Message-ID: <D7A0423E5E193F40BE6E94126930C493078D7343F8@MBCLUSTER.xchange.nist.gov>
References: <4eb512450912232027l730a767cnc8e3192c5eaa1c41@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C493078D7343EE@MBCLUSTER.xchange.nist.gov>, <4eb512450912292310s30bec5aex3e1f5edc98852178@mail.gmail.com>
In-Reply-To: <4eb512450912292310s30bec5aex3e1f5edc98852178@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov
Cc: "rrg@irtf.org" <rrg@irtf.org>
Subject: Re: [rrg] Questions about Enhanced Efficiency of Mapping Distribution Protocols
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Dec 2009 16:06:23 -0000

________________________________________
From: Charrie Sun [charriesun@gmail.com]
Sent: Wednesday, December 30, 2009 2:10 AM
To: Sriram, Kotikalapudi
Cc: rrg@irtf.org
Subject: Re: Questions about Enhanced Efficiency of Mapping Distribution        Protocols

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

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).

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