[RAM] TIDR using the IDENTIFIERS attribute
JUAN-JOSE.ADAN@giss.seg-social.es Thu, 19 April 2007 13:19 UTC
Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWXU-0002G5-D3; Thu, 19 Apr 2007 09:19:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWXT-0002Fz-Gn for ram@iab.org; Thu, 19 Apr 2007 09:19:07 -0400
Received: from giss7a.seg-social.es ([194.179.55.135] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeWXS-0006Rk-JM for ram@iab.org; Thu, 19 Apr 2007 09:19:07 -0400
Received: from gwsalida1.correo.portal.ss ([10.99.1.224]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JGQYBO01.TC2 for <ram@iab.org>; Thu, 19 Apr 2007 15:19:00 +0200
X-Priority: 1 (High)
To: ram@iab.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: <OF56D1B868.4680C0B4-ONC12572C2.00426509-C12572C2.00428301@tgss.seg-social.es>
From: JUAN-JOSE.ADAN@giss.seg-social.es
Date: Thu, 19 Apr 2007 14:06:28 +0200
X-MIMETrack: Serialize by Router on GWSALIDA1/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 19/04/2007 15:18:58, Serialize complete at 19/04/2007 15:18:58
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75
Subject: [RAM] TIDR using the IDENTIFIERS attribute
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1023470573=="
Errors-To: ram-bounces@iab.org
Hi all, I am sending you the mail I promised on Monday. I think we have mainly two problems to solve: (1) scalability of the global BGP table, (2) BGP churn. (1) SCALABILITY OF THE ROUTING TABLE We have several thousands of autonomous systems in the Internet, and we treat all of them in the same way whether they are transit or non-transit AS-es. But we shouldn´t forget that only 1/6 are transit AS-es. And most likely this fraction is decreasing over time (any figures?). In the draft on "Tunneled Inter-domain Routing (TIDR)" I presented a push method based on the use of tunnels which are announced using the LOCATOR attribute. It is the presence of the LOCATOR attribute what permits to say whether a prefix is a "locator prefix" or an "identifier prefix". This separation will allows us to treat these two types of prefixes differently. But this separation can be achieved either using the LOCATOR attribute to assign locators to identifiers, or by using the IDENTIFIERS attribute to specify which identifiers can be reached through the locator specified in the NLRI of the BGP update. In TIDR, scalability of the routing table is achieved because whereas "locator prefixes" are still stored in the RIB, "identifier prefixes" are moved to the TIB. As a consequence of this, the RIB eventually will only store the "locator prefixes" of the transit AS-es. (2) BGP CHURN As Heiner Hummel pointed out "with Hierarchical Routing the routing churn rate will dramatically be reduced". I think he is right, because with hierarchical routing not all parts of the network are equally important. So that, an announcement or withdrawal of an "identifier prefix" will be far less important than that of a "locator prefix". The addition of a new attribute to BGP (LOCATOR, IDENTIFIERS, or both) obviously increases the amount of information that must be flooded by BGP. But in my opinion, the main problem is not this increase in the amount of information but the fact that a change in a leaf AS using PI addressing implies to modify the RIB and FIB of all the routers in the DFZ. In other words, the problem is not to force every router in the entire DFZ to carry an advertisement for site X's PI-prefix. The most important problem is that it has to use this announcement for routing, i.e. it has to install it in the RIB and download it into the FIB. With TIDR things improve because this announcement will not modify the RIB but only the TIB. Therefore, if we want to reduce the effect of the route churn on the BGP convergence we will have to modify BGP so that a change in the identifier-locator map will not affect the interdomain routing system (more specifically the RIB of DFZ routers) but only the TIB. So, we need two types of BGP updates: "routing updates" and "mapping updates". Let's use for example the block 240.0.0.0/8 to assign "locator prefixes" to transit AS-es so that, for instance, AS1 will use the block 240.0.1.0/24 for "locator prefixes". Please notice that this is just an example to explain the inner workings of my proposal. I think it is very important to use a specific range of IP addresses for TIDR routing so that a transit AS is assigned an address block easy to identify. The ORIGIN attribute is a mandatory attribute that must be always present in any BGP update. At present this attribute can have one of the following values: - IGP: the NLRI is interior to the originating AS - EGP: NLRI learned via the EGP protocol - Incomplete: NLRI learned by some other means The ORIGIN=EGP value is no longer used. Therefore I propose to reinterpret this value as EXTERNAL (to keep the first letter the same), or to define a fourth value for the ORIGIN attribute, whatever is simpler. If the latter is simpler we could define ORIGIN=MAPPING to indicate that the BGP update is just for ID-LOC mapping. Bearing this in mind we proceed to distinguish the two aforementioned types of BGP updates: - "routing updates": these are the current type of updates. They carry ORIGIN IGP or INCOMPLETE. They are used to modify the RIB. - "mapping updates": they carry ORIGIN EXTERNAL or MAPPING, and are used to modify the TIB. They carry the IDENTIFIERS attribute to specify the set of "identifier prefixes" that can be reached through the locator specified in the NLRI of the update. They will be treated with a priority lower than "routing updates". With these two types of BGP updates we separate routing events (those affecting the interdomain infrastructure) from those updates caused by changes in the ID-LOC mapping. Following the above example, AS1 will generate "routing updates" to announce prefix 240.0.1.0/24 or even longer prefixes that will remain inside the interdomain routing infrastructure. What means that transit AS-es will never propagate these announcements to their leaf customers, for they are outside the interdomain infrastructure. And AS1 will also generate "mapping updates" to specify within the IDENTIFIERS attribute which "identifier prefixes" can be accessed by sending tunneled traffic to the locator which is specified in the NLRI. Notes: a) I have continued to use LOCATOR as the name of the first new attribute that I proposed in the TIDR draft, but notice that this attribute can be used to store several locators. Therefore the name can be changed to LOCATORS. b) When I say PI-prefix I also mean a deaggregated PA-prefix. Any comments?. Regards, Juanjo
_______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] TIDR using the IDENTIFIERS attribute JUAN-JOSE.ADAN
- Fraction of transit ASes going down? [Re: [RAM] T… Simon Leinen
- Re: Fraction of transit ASes going down? [Re: [RA… Ricardo V. Oliveira
- Re: Fraction of transit ASes going down? [Re: [RA… JUAN-JOSE.ADAN