Robin, Here is what I think about RANGER and scalable routing. RANGER expects that the existing state of affairs in the current Internet BGP routing system will persist, but the goal of RANGER is to arrest the growth of the BGP RIB so that it will level off and not continue to expand along super-linear rates. In particular, RANGER expects that the current BGP will continue to maintain the RLOC-based RIB for the Internet, but that future growth due to mobility, multihoming and PI addressing will be handled out of EID space instead of RLOC space.
RANGER asks that a new BGP instance that carries EID prefixes be established within the DFZ, where each participating EID-based BGP router is an ITR/ETR that treats the DFZ as a virtual NBMA link through tunneling. Each participating EID-BGP router will set up peering arrangements with a limited set of neighbors using tunnels according to the NBMA link model. There is no requirement that these EID-BGP routers also participate in the current RLOC-based BGP routing instance, so the EID-BGP routers can be deployed incrementally and without disturbing the existing RLOC-BGP routing system. This new EID-BGP instance will be used for carrying a relatively small number of highly-aggregated EID prefixes in keeping with the principles of Virtual Aggregation (VA). So, this new EID-BGP instance (which again is completely separate from the existing RLOC-BGP instance) will carry only highly-aggregated Virtual Prefixes (VPs) such as 4000::/8, 4100::/8, etc. So, at most there will be perhaps a few thousand of these VPs in the EID-BGP RIB (or perhaps even a few 10's or 100's of thousands) but the RIB size will be kept manageable through VA. Now, RANGER has the EID-based VPs populated throughout the EID-BGP RIB, with all of the EID-BGP routers connecting service provider (SP) networks via the virtual NBMA link configured over the core. Customer Edge (CE) routers within the SP networks will want to use EID-based PI prefixes. Each such CE router "registers" its EID PI prefixes both within the SP network and with the EID-BGP routers that own the VP from which the PI prefix is aggregated. Once "registered", the CE's PI prefix will be kept only in selected router FIBs, and will not be injected into the EID-BGP RIB. Moreover, only the FIBs of those routers on the paths over which the CE's EID addressed packets will travel need to contain the PI prefix - no other routers need discover the prefix. The location of the CE router's EID prefix is tracked through the FIB entries in the EID-BGP router that holds the VP from which the EID prefix is derived. In summary, the RANGER approach to scalable routing is to create a new BGP instance between tunnel routers for the purpose of keeping a limited set of highly-aggregated EID VPs in the RIB. PI EID prefixes owned by customer routers are added to selected SP router FIB tables on demand, and are never injected into the RIB. The way this works is that CE routers that are holders of PI EID prefixes "blow bubbles" that percolate up through a reverse tree ascending through their SP networks until the bubbles reach an EID-BGP router that owns a VP from which the PI prefix is derived. In that way, the locations of all PI EID prefix holders are available in EID-BGP router FIBs while only VPs appear in the EID-BGP RIB. This system of knowing where all PI prefix holders are at all times also has clear beneficial properties for supporting mobility and multihoming. Finally, in terms of routing scaling, the end state benefit is that both the EID-BGP and RLOC-BGP RIBs remain manageable in size and only those routers that need to know about certain PI EID prefixes have to carry those prefixes in their FIBs. Any thoughts or comments on this? Fred [email protected] > -----Original Message----- > From: Robin Whittle [mailto:[email protected]] > Sent: Tuesday, January 26, 2010 4:53 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] RANGER and SEAL critique > > Hi Fred, > > I am keen for you to provide a guide to exactly how RANGER would > be used for scalable routing, with details of the mapping system, > multihoming, TE and mobility etc. and why this would be a better > choice than LISP or Ivip. > > The only other CES architecture, TIDR, can't solve the biggest > single scaling problem - the burden on the DFZ control plane due > to each additional end-user prefix. > > The 6 or so CEE proposals are not suitable for widespread > voluntary adoption, and I think I will argue against them on > other grounds as well. The remaining proposals are not full > solutions to the routing scaling problem. > > So that leaves LISP, RANGER and Ivip. > > > You wrote: > > > I will respond to the RANGER portion of the critique later, > > but in terms of the SEAL portion please be sure you are > > evaluating the correct version. The latest SEAL spec is > > found here: > > > > http://tools.ietf.org/html/draft-templin-intarea-seal > > > > and fully supports jumbograms. > > Yes - I was referring to an earlier version. > > > My critique of RANGER was based on: > > http://tools.ietf.org/rfcmarkup?rfc-repository=http://www.rfc- > editor.org/authors&doc=rfc5720&topmenu=true&document=draft-templin-ranger-09&docreplaces=draft- > templin-ranger-09&title=RFC-EDITOR+AUTH48+REVIEW+COPY&extrastyle=body+{background-color:%23fee%3b} > > This is an RFC-to-be 5720 "January 2010" which I found by > clicking a link "RFC-to-be" at the top of: > > http://tools.ietf.org/html/draft-templin-ranger-09 (26 October 2009) > > > My critique of SEAL was based on: > > http://tools.ietf.org/rfcmarkup?rfc-repository=http://www.rfc- > editor.org/authors&doc=rfc5320&topmenu=true&document=draft-templin-seal-23&docreplaces=draft-templin- > seal-23&title=RFC-EDITOR+AUTH48+REVIEW+COPY&extrastyle=body+{background-color:%23fee%3b} > > This is an RFC-to-be 5320 "January 2010" which I found by > clicking a link "RFC-to-be" at the top of: > > http://tools.ietf.org/html/draft-templin-seal-23 (28 October 2008) > > > The RANGER summary: > > http://www.ietf.org/mail-archive/web/rrg/current/msg05665.html > > links to draft-templin-ranger-09, so it seems I was looking at > the correct RANGER document. I see now that the summary links to > the later SEAL document "draft-templin-intarea-seal-08". > > Searching for SEAL with the Google option at: > http://tools.ietf.org/html/ will lead most people to the > "draft-templin-seal-23" page, since this is currently the first > search result. > > Can you terminate this zombie strand of SEAL IDs, especially > since it leads to an apparently up-to-date RFC-to-be? > > This prompted me to realise I have a dead-end ID: > > draft-whittle-ivip4-etr-addr-forw-01 > > which is continued under another name, without the '4'. I will > post a short -02 version to point people to the new IDs. > > In http://tools.ietf.org/html/draft-templin-ranger-09 the SEAL > reference does link to draft-templin-intarea-seal-07, but in the > RFC-to-be - which is a later version of draft-templin-ranger-09 - > the SEAL reference doesn't link to anything. It does give a > later date - October 2009 - than the October 2008 date of > draft-templin-seal-23, but that is easily missed. So people > are likely to use the Google facility and pick the top result, > which has an impressively high version number, and then > follow the link to the RFC-to-be 5320, which displays a January > 2010 date. > > I will look at the latest SEAL draft: > > http://tools.ietf.org/html/draft-templin-intarea-seal-re-02 > > > - Robin > > > > > > > > > > > > > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
