Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Hi Robin, > -Original Message- > From: Robin Whittle [mailto:[email protected]] > Sent: Thursday, March 18, 2010 6:38 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Hi Fred, > > I will try to use for your simpler arrangement for naming the IRON > routers, but I still find it easiest to think and write in terms of > some roles I mentioned, which have no exact name in your arrangement. OK; I speak more to this below. > When I referred to "BR" I mean a router in an AS which also connects > to other ASes - so I was referring to its status in the interdomain > routing system, not whether it was a "Border" router from the > perspective of the I-R overlay network. You use "BR" to refer to the > router's status within the I-R network. Actually, the IRON BR is a router that connects an enterprise network to a different enterprise network - whether within the same AS or in a different AS. > I only spent a few minutes looking at VRRP - and without trying to > understand how it uses multicast, I thought maybe multicast of any > kind would be difficult or impossible on the I-R overlay network. I > wasn't suggesting this was definitely the case. The assumption I have been making is that there is a shared link in an underlying network over which the VRRP multicasts are exchanged. This would not affect the IRON in any way. But, I believe we can relax the role of VRRP to where it can be considered as only an optimization and not a fundamental underpinning of the architecture. > You wrote, in part: > > > Consider that all IRON > > routers are IRON border routers (IBRs), in that they > > connect zero or more EID-based enterprise networks to > > the IRON. Each IBR: > > > > - participates in the IRON overlay routing protocol > > - advertises zero or more VPs into the routing protocol > > - connects zero or more EID-based enterprise networks to > > the IRON > > - may or may not connect the IRON to the DFZ > > > > I choose to view this latter category as "gateways" from > > the IRON to the DFZ, so I will call these as IBGs. So, > > we now simply have only IBRs and IBGs. > > OK. But those which advertise VPs have many extra responsibilities, > so I think it is important to think of something like a VP Router, or > the VP role or something as a distinct entity which some IBRs or IBGs > have and which the rest don't. Right; that's why I say an IBR can service _zero or more_ VPs. > > What I am calling "Border Router (BR)" is any router that > > can be used for getting off the IRON and onto either an EID- > > based enterprise network or onto the DFZ. > > "getting off the IRON" implies to me that packets sent along the I-R > overlay would be handled by this IRON router and forwarded to the > EID-based enterprise network (what I referred to as and "EID-using > end-user network") or towards some arbitrary host on the Internet > (IPv4 and/or IPv6?) via forwarding to other routers (the DFZ). > > I don't understand this because the I-R overlay network doesn't > handle traffic packets. Not so - the IRON is used both for control plane and forwarding plane, and both use ITE->ETE tunneling. > It only handles BGP best path communications > between the IRON routers so each IRON router can discover the IP > address (the Internet address and I-R overlay addresses are the same) > of routers which advertise in the I-R overlay some particular prefix. > The only IRON routers in the I-R overlay which advertise anything > into the overlay are those which advertise a VP. If two or more > advertise a VP, then with BGP, every IRON router will get a best path > to one of these VP routers, and so find out the IP address of one of > them. The IRON is used for: - BGP exchanges of VPs so that the next hop addresses of all IBRs that hold VPs can be determined - initial data packets sent to an IBR that holds a VP that covers the EID destination address prefix - secure redirection from the VP-holding IBR to an IBR that has a more-specific route to the final destination - subsequent forwarding plane traffic from an IBR's ITE to the ETE of an IBR that has a more-specific route to the final destination > No traffic packets are sent over the I-R network. When an IRON > router performing the IBG or IBR role tunnels a packet to an IRON > router which advertises a VP in the overlay, the tunnel is via the > Internet. The IRON is an overlay over the Internet, and it is used for both control and forwarding plane. > So I don't understand what
Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Hi Fred, I will try to use for your simpler arrangement for naming the IRON routers, but I still find it easiest to think and write in terms of some roles I mentioned, which have no exact name in your arrangement. When I referred to "BR" I mean a router in an AS which also connects to other ASes - so I was referring to its status in the interdomain routing system, not whether it was a "Border" router from the perspective of the I-R overlay network. You use "BR" to refer to the router's status within the I-R network. I only spent a few minutes looking at VRRP - and without trying to understand how it uses multicast, I thought maybe multicast of any kind would be difficult or impossible on the I-R overlay network. I wasn't suggesting this was definitely the case. You wrote, in part: > Consider that all IRON > routers are IRON border routers (IBRs), in that they > connect zero or more EID-based enterprise networks to > the IRON. Each IBR: > > - participates in the IRON overlay routing protocol > - advertises zero or more VPs into the routing protocol > - connects zero or more EID-based enterprise networks to > the IRON > - may or may not connect the IRON to the DFZ > > I choose to view this latter category as "gateways" from > the IRON to the DFZ, so I will call these as IBGs. So, > we now simply have only IBRs and IBGs. OK. But those which advertise VPs have many extra responsibilities, so I think it is important to think of something like a VP Router, or the VP role or something as a distinct entity which some IBRs or IBGs have and which the rest don't. > What I am calling "Border Router (BR)" is any router that > can be used for getting off the IRON and onto either an EID- > based enterprise network or onto the DFZ. "getting off the IRON" implies to me that packets sent along the I-R overlay would be handled by this IRON router and forwarded to the EID-based enterprise network (what I referred to as and "EID-using end-user network") or towards some arbitrary host on the Internet (IPv4 and/or IPv6?) via forwarding to other routers (the DFZ). I don't understand this because the I-R overlay network doesn't handle traffic packets. It only handles BGP best path communications between the IRON routers so each IRON router can discover the IP address (the Internet address and I-R overlay addresses are the same) of routers which advertise in the I-R overlay some particular prefix. The only IRON routers in the I-R overlay which advertise anything into the overlay are those which advertise a VP. If two or more advertise a VP, then with BGP, every IRON router will get a best path to one of these VP routers, and so find out the IP address of one of them. No traffic packets are sent over the I-R network. When an IRON router performing the IBG or IBR role tunnels a packet to an IRON router which advertises a VP in the overlay, the tunnel is via the Internet. So I don't understand what you mean by: > getting off the IRON and onto either an EID- > based enterprise network or onto the DFZ. (But see potential explanation a few paragraphs down.) > In this sense, > any router that "sinks" EID-addressed packets that do not > belong to either an EID-based enterprise network nor the > DFZ is also considered as a BR. I don't see how this would be needed. No IRON router receives traffic packets on the overlay - the overlay is simply a mechanism by which IRON routers discover the "nearest" IRON router which is advertising a VP. As I wrote previously (and as is quoted below in points 1 and 2), there are two reasons for doing this. One is to tunnel a traffic packet to that VP router. The other is to register an EID prefix with that VP router and with the other VP routers which advertise the VP which covers this EID prefix. >> However, a subset of IRON routers are BRs and are also configured to >> perform the IDM role. While a router could perform purely this IDM >> role and not advertise the edge prefixes locally, I will assume this >> would not be typical. > > All IRON routers are BRs (IBRs). Some IBRs are also > gateways for getting off the IRON and onto the DFZ. > These are called IBGs. Oh - you mean the IBG advertises all I-R "edge" prefixes, (perhaps as one or a few prefixes in IPv6, though probably many would be required for IPv4) and that this means it acts like an Ivip DITR or LISP PTR - accepting traffic packets sent by other ASes which lack their own IRON routers and then tunneling them firstly to an VP router, and then (after the VP router sends back "mapping") to an IRON router which can deliver the packet to its destination network. I wouldn't describe this as "getting off the IRON and onto the DFZ" - except in terms of the flow of advertisements of routes. I tend to think more in terms of the flow of packets rather than the flow of information about routes to particular prefixes. >> A VPR need not be a BR. It need not perform any other roles, but I >> guess it typi
Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Hi Robin, Thanks for the continued discussion: > -Original Message- > From: Robin Whittle [mailto:[email protected]] > Sent: Wednesday, March 17, 2010 7:51 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Short version: Continuing discussions: > > Is OSPF suitable for the I-R overlay? BGP is > highly decentralised, but I am not sure this is > the case with OSPF. This clearly needs further investigation, which I will be working from my end. I fully believe there is a good fit to be found. > Fred suggests Virtual Router Redundancy Protocol > (VRRP) RFC 5798 for the task of "DEL" routers > registering their EID prefixes with a handful of > VP routers. My initial impression is that this > won't work because it requires multicast - which > I think would be impossible or at least > unscalable on a global overlay network as I-R > requires. The multicast required is only link-local multicast on a shared link that connects the multiple VP routers. The "link" could be an ordinary physical link, or it could even be a mesh of tunnels of some form. But, the multicast scope is link-local only - it is not IRON-wide nor Internet-wide multicast. I think VRRP fits the purpose. > I give some names to the various roles I think > IRON routers might have, and consider what > combinations of roles might be valid. I don't want to add lots of new acronyms for this, as it rapidly becomes too complex to follow while the situation itself is really quite simple. Consider that all IRON routers are IRON border routers (IBRs), in that they connect zero or more EID-based enterprise networks to the IRON. Each IBR: - participates in the IRON overlay routing protocol - advertises zero or more VPs into the routing protocol - connects zero or more EID-based enterprise networks to the IRON - may or may not connect the IRON to the DFZ I choose to view this latter category as "gateways" from the IRON to the DFZ, so I will call these as IBGs. So, we now simply have only IBRs and IBGs. > Hi Fred, > > Continuing our interesting conversation on the design of IRON-RANGER, > you wrote: > > >> I assumed that these "DITR-like" routers were not necessarily VP routers. > > > > Correct; these routers (IDMs) may also be VP routers on > > the IRON but need not be. So, we have three classes of > > IRON routers: 1) VP routers, 2) IDMs, and 3) both. > > I understand the population of IRON routers can be classified > according to their roles. I am giving some new names to these roles. > > I think it is important to invent names for concepts in a new design, > otherwise we have to use phrases which are longer, and might be > written in different ways when they really refer to the same thing. > >DEL Delivers packets to one or more nearby end-user networks, and >so needs to register the one or more EID prefixes this >involves with VP routers (VPRs). (Typically 2 VPRs, but >I tend to think of 2, 3 or 4 or so for robustness.) > > >LFR Local Forwarding Router. Advertises a few prefixes covering >all I-R "edge" space in the local routing system of the >network it is located in. For the purposes of discussion, I >will assume this is an ISP network, but it could be the >network of a large end-user network which has its own AS and >participated in the interdomain routing system. > >This router is not advertising anything outside the ISP >network - so it is not "advertising I-R edge space in the >DFZ". > >Any packets addressed to I-R edge space (that is to any >EID prefix used by an I-R-using end-user network) will >go to this router rather than to the ISP's BRs. So this >router needs to tunnel it to one of the VPRs for the VP this >EID address is within. That VPR doesn't have to be the >"closest" of the two or more VPRs, but if you use BGP in the >overlay network then it typically will be the "closest" in BGP >terms - which would be desirable, to reduce path lengths and >delays for the one or more initial packets which go via the >VPR. That VPR will tunnel the packet to the IRON router >playing the DEL role. The VPR will also send mapping to >this LFR-rol
Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Hi Robin, Responding again: > -Original Message- > From: Robin Whittle [mailto:[email protected]] > Sent: Tuesday, March 16, 2010 5:30 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Short version: Further discussion on "DITR-like" routers, now > called "IRON Default Mappers" (IDMs), how an IRON > router registers an end-user network EID prefix > with multiple VP routers, and whether to use OSPF > rather than BGP for the IRON overlay network. > > > Hi Fred, > > You wrote: > > >> OK - so these are the I-R equivalents of Ivip's DITRs (Default ITRs > >> in the DFZ) and LISP PTRs. In my previous message, I assumed that VP > >> routers were also advertising their VPs in the DFZ. I recall I got > >> this from something you wrote, but it doesn't matter now. > >> > >> But what are the scaling properties of these routers I will refer to > >> as being "DITR-like"? > >> > >> Who runs them? They are doing work, handling packets addressed to > >> very large numbers of I-R end-user network prefixes, who are the > >> parties which benefit. So I think there needs to be an arrangement > >> for money to flow from those end-user networks, in rough proportion > >> to the traffic each DITR-like router handles for each end-user > >> network. This is handled in Ivip, but with DITRs which advertise > >> specific subsets of the MABs (Mapped Address Blocks): > >> > >> http://tools.ietf.org/html/draft-whittle-ivip-arch-04#section-8.1.2 > >> > >> I suggest you devise a business case for these "DITR-like" routers - > >> and give them a name. > > > > The more I think about it, the more these specialized > > VP routers are really just Default Mappers, i.e., the > > similar to those discussed in APT. On the IRON, they > > advertise "default", and on the DFZ they advertise one > > or a few short prefixes (e.g., 4000::/3) that cover all > > of the VPs in use on the IRON. > > This is different from what I understood from your previous message. > > I understood there was a subset of IRON routers which we call "VP > routers". Each such "VP router" advertises in the IRON network (the > tunnel-based overlay network between all IRON routers, currently > implemented with BGP) a VP (Virtual Prefix). There are typically two > or perhaps more such routers advertising a given VP. Each such VP > router may also advertise other VPs, but for this discussion, let's > think of IRON routers A, B and C all advertising VP "P" on the IRON > network - and for the purposes of discussion not advertising any > other VPs. OK. > After your msg06274, when I wrote msg06278, I understood that the VP > routers also advertised their VPs in the DFZ, and that this was the > mechanism by which I-R supported packets sent by hosts in > non-upgraded networks. It doesn't matter now why I thought this. > > From the most recent pair of messages, your msg06305 and my msg06315, > I thought that this role, which I described as "DITR-like" was > performed by a subset of IRON routers which advertise one or a few > prefixes in the DFZ which covers the entire I-R "edge" subset of the > global unicast address space. This was on the basis of your: > >>> Firstly, if these VP-advertising routers are to operate >>> properly like DITRs or PTRs, there needs to be a lot more than >>> 2 of them per VP. >> >> No, because all that needs to be injected into the DFZ is >> one or a few very short prefixes (e.g., 4000::/3). It doesn't >> matter then which IRON router is chosen as the egress to get >> off of the DFZ, since that router will also have visibility >> to all VPs on the IRON. > >> Again, DFZ routers on the non-upgraded network would select >> the closest IRON router that advertises, e.g., 4000::/3 as >> the router that can get off the DFZ and onto the IRON. So, >> it would not be the case that all VPs would be injected into >> the DFZ. > > I assumed that these "DITR-like" routers were not necessarily VP routers. Correct; these routers (IDMs) may also be VP routers on the IRON but need not be. So, we have three classes of IRON routers: 1) VP routers, 2) IDMs, and 3) both. > Here is my understanding on what you just wrote: > > > The more I think about it, the
Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Hi Robin, Thanks for your follow up, and I will try to keep my responses brief (below): > -Original Message- > From: Robin Whittle [mailto:[email protected]] > Sent: Tuesday, March 16, 2010 4:40 AM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Short Version:Fred describes a method for handling packets sent > from by non-upgraded networks - roughly similar > to Ivip's DITRs and LISP's PTRs. However there > are unresolved questions about the commercial > arrangements for running these. > > With this arrangement, my prior assumption that > there be 20 or so routers advertising a given VP > (because I had understood these were performing the > DITR/PTR functions) does not apply. > > This reduces the the scaling difficulties I had > previously mentioned. > > But there is not yet a clearly defined method of > registering with the 2 or 3 VP routers. We discuss > some of the scaling problems and workarounds for > them - but a fuller discussion will depend on > Fred's choice of registration mechanism. He is > contemplating replacing the overlay network's BGP > with OSPF, but maybe there's a way of doing it > while retaining BGP. > > > > Hi Fred, > > You wrote: > > > >> I think I-R needs to be described in a way that someone who is up to > >> speed on scalable routing in general can read one or perhaps two I-R > >> documents and have a good idea of how the whole thing is going to > >> work - including with respect to scaling and security. This doesn't > >> require exact bits in headers, but that could be part of it. I think > >> it needs to be pretty-much self-contained rather than requiring > >> people to read other documents which are not part of I-R. > > > > There is room in a future update to IRON to improve on this. > > OK. > > > >>>> For instance, how many IRON routers are there in an IPv4 I-R system, > >>>> and how many individual EID prefixes? > >>> > >>> Let's suppose that each VP is an IPv6 ::/32, and that > >>> the smallest unit of PI prefix delegation from a VP is > >>> an IPv6 ::/56. In that case, there can theoretically be > >>> up to 4B VPs in the IRON RIB and 16M PI prefixes per VP. > >>> In practice, however, we can expect to see far fewer than > >>> that until the IPv6 address space reaches exhaustion > >>> which many believe will be well beyond our lifetimes. > >> > >> OK. Still, depending on how the address space was allocated - or at > >> least that subset of the address space covered by I-R's VPs - there > >> could be high numbers, approaching 16M perhaps, of I-R PI prefixes > >> per VP. > > > > Well, this is a tunable knob of course. We could for > > example set the length for VPs to ::/36, ::/40, etc. > > to reduce the number of PI prefixes per VP. > > > > The tradeoff is in managing a RIB containing a large > > number of VPs (which are likely to be quite stable) vs. > > managing a large number of PI prefixes per VP (which > > require periodic keepalives to maintain). So, given a > > routing protocol that can maintain a large number of > > VPs in a relatively static topology it seems like a > > proper balance of PI prefixes per VP can be found. > > OK. > > >>> Still thinking (very) big, let's try sizing the system > >>> for 100K VPs; each with 100K ::/56 delegated PI prefixes. > >>> That would give 10B ::/56 PI prefixes, or 1 PI prefix > >>> for every person on earth (depending on when you sample > >>> the earth's population). Let's look at the scaling > >>> considerations under these parameters: > >> > >> OK, I think this is a good scenario to discuss. I assume that the > >> VPs can be of various sizes, so some VPs could be a longer prefix, > >> covering less space, if there are a larger number of I-R PI prefixes > >> within that part of the address space. > > > > The length of the VPs is a tunable. It may be that there > > can be VPs of varying lengths, but I chose to discuss as > > all VPs having the same length
Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Robin, See below for some follow-up: > -Original Message- > From: Robin Whittle [mailto:[email protected]] > Sent: Friday, March 12, 2010 7:11 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Short version:Exploring the scalability of IRON-RANGER's > "bubble"-based registration system - every > 10 minutes the two IRON routers of the two > ISPs send a registration packet to however > many VP (Virtual Prefix) Iron routers there > are for the VP which covers the I-R PI > prefix in question. > > I think the scaling properties of this > system look bad - and I can't yet see how > the IRON routers can discover the IP addresses > of all the VP routers. > > > Hi Fred, > > You wrote: > > >>> IRON-RANGER used to speak of using IPv6 neighbour discovery > >>> as the means for locator liveness testing, dissemination > >>> of routing information, secure redirection, etc. However, > >>> the VET and SEAL mechanisms are being revised to instead > >>> use a different mechanism called the SEAL Control Message > >>> Protocol (SCMP) for tunnel endpoint negotiations that occur > >>> *within* the tunnel sublayer and are therefore not visible > >>> to either the outer IP protocol nor the inner network layer > >>> protocol. Hence, the inner network layer protocol could be > >>> anything, including IPv4, IPv6, OSI CLNP, or any other network > >>> layer protocol that is eligible for encapsulation in IP. > >> > >> OK. I hope you will be able to explain these things not just in > >> terms of high-level concepts, but to give examples of how the whole > >> thing would actually work on a large scale. > > > > OK if you are talking about an architectural description, > > but please note that both VET and SEAL are already full > > functional specifications that can be used by software > > developers to produce real code. > > I think I-R needs to be described in a way that someone who is up to > speed on scalable routing in general can read one or perhaps two I-R > documents and have a good idea of how the whole thing is going to > work - including with respect to scaling and security. This doesn't > require exact bits in headers, but that could be part of it. I think > it needs to be pretty-much self-contained rather than requiring > people to read other documents which are not part of I-R. There is room in a future update to IRON to improve on this. > >> For instance, how many IRON routers are there in an IPv4 I-R system, > >> and how many individual EID prefixes? > > > > Let's suppose that each VP is an IPv6 ::/32, and that > > the smallest unit of PI prefix delegation from a VP is > > an IPv6 ::/56. In that case, there can theoretically be > > up to 4B VPs in the IRON RIB and 16M PI prefixes per VP. > > In practice, however, we can expect to see far fewer than > > that until the IPv6 address space reaches exhaustion > > which many believe will be well beyond our lifetimes. > > OK. Still, depending on how the address space was allocated - or at > least that subset of the address space covered by I-R's VPs - there > could be high numbers, approaching 16M perhaps, of I-R PI prefixes > per VP. Well, this is a tunable knob of course. We could for example set the length for VPs to ::/36, ::/40, etc. to reduce the number of PI prefixes per VP. The tradeoff is in managing a RIB containing a large number of VPs (which are likely to be quite stable) vs. managing a large number of PI prefixes per VP (which require periodic keepalives to maintain). So, given a routing protocol that can maintain a large number of VPs in a relatively static topology it seems like a proper balance of PI prefixes per VP can be found. > > Still thinking (very) big, let's try sizing the system > > for 100K VPs; each with 100K ::/56 delegated PI prefixes. > > That would give 10B ::/56 PI prefixes, or 1 PI prefix > > for every person on earth (depending on when you sample > > the earth's population). Let's look at the scaling > > considerations under these parameters: > > OK, I think this is a good scenario to discuss. I assume that the > VPs can be of various sizes, so some VPs could be a longer prefix, > covering less space, if there are a larger number of I-R PI prefixes > within that part of the address
Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Hi Robin - see below for some follow-up: > -Original Message- > From: Robin Whittle [mailto:[email protected]] > Sent: Thursday, March 11, 2010 4:18 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Hi Fred, > > Thanks for this: > > > In catch-up mode, your suggestion of a need for more > > discussion of scaling properties is a good one, and > > something I think that can be accommodated in the > > next IRON update. > > Also, in "Re: [rrg] Why won't supporters of Loc/ID Separation ..." > you wrote: > > > IRON-RANGER used to speak of using IPv6 neighbour discovery > > as the means for locator liveness testing, dissemination > > of routing information, secure redirection, etc. However, > > the VET and SEAL mechanisms are being revised to instead > > use a different mechanism called the SEAL Control Message > > Protocol (SCMP) for tunnel endpoint negotiations that occur > > *within* the tunnel sublayer and are therefore not visible > > to either the outer IP protocol nor the inner network layer > > protocol. Hence, the inner network layer protocol could be > > anything, including IPv4, IPv6, OSI CLNP, or any other network > > layer protocol that is eligible for encapsulation in IP. > > OK. I hope you will be able to explain these things not just in > terms of high-level concepts, but to give examples of how the whole > thing would actually work on a large scale. OK if you are talking about an architectural description, but please note that both VET and SEAL are already full functional specifications that can be used by software developers to produce real code. > For instance, how many IRON routers are there in an IPv4 I-R system, > and how many individual EID prefixes? Let's suppose that each VP is an IPv6 ::/32, and that the smallest unit of PI prefix delegation from a VP is an IPv6 ::/56. In that case, there can theoretically be up to 4B VPs in the IRON RIB and 16M PI prefixes per VP. In practice, however, we can expect to see far fewer than that until the IPv6 address space reaches exhaustion which many believe will be well beyond our lifetimes. Still thinking (very) big, let's try sizing the system for 100K VPs; each with 100K ::/56 delegated PI prefixes. That would give 10B ::/56 PI prefixes, or 1 PI prefix for every person on earth (depending on when you sample the earth's population). Let's look at the scaling considerations under these parameters: > Then, how do these IRON > routers, for each of these EID prefixes continually and repeatedly (I > guess every 10 minutes or less) securely inform a given number of VP > routers they are the router, or one of the routers, to which packets > matching a given EID prefix should be tunneled. Since there could be > multiple VP routers for a given VP, and the IRON routers don't and (I > think) can't know where they are, how does this process work securely > and scalably? Each IRON router R(i) discovers the full map of VPs in the IRON through participation in the IRON BGP. That means that each R(i) would need to perform full database synchronization for 100K stable IRON RIB entries that rarely if ever change. This doesn't sound terrible even for existing core router equipment. As you noted, it is also possible that a given VP(j) would be advertised by multiple R(i)s - let's say each VP(j) is advertised by 2 R(i)s (call them R(x) and R(y)). But, since the IRON RIB is fully populated to all R(i)s, each R(i) would discover both R(x) and R(y) that advertise VP(j). Now, for IRON router R(i) that is the provider for 100K PI prefixes delegated from VP(j), R(i) needs to send a "bubble" to both R(x) and R(y) for each PI prefix. That would amount to 200K bubbles every 600 sec, or 333 bubbles/sec. If each bubble is 100bytes, the total bandwidth required for updating all of the 100K PI prefixes is 260Kbps. Now, let's say that each PI prefix is multihomed to 2 providers, then we get 2x the message traffic for 520Kbps total for the bubbles needed to keep the 100K PI prefixes refreshed. > If the VP routers act like DITRs or PTRs by advertising their VP in > the DFZ, then in order to make them work well in this respect - to > generally minimise the extra path length taken to and from them > compared to the path from the sending host to the proper IRON router > - I think you need at least a dozen of them. This directly drives > the scaling problems in the process just mentioned where the IRON > routers continually register each of their EID prefixes with the > dozen or so VP routers which cover that EID prefix. I don't understand why the dozen - I think with IRON VP routers, the only
Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Robin, In catch-up mode, your suggestion of a need for more discussion of scaling properties is a good one, and something I think that can be accommodated in the next IRON update. Thanks - Fred [email protected] > -Original Message- > From: Robin Whittle [mailto:[email protected]] > Sent: Tuesday, March 09, 2010 6:18 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Hi Fred, > > You wrote: > > >> I don't understand the mechanisms by which potentially very large > >> numbers of IRON routers repeatedly and continually register with > >> potentially multiple VP routers. These IRON routers could be > >> anywhere and so could the VP routers. In that message, the most I > >> can discern about this mechanism is: > >> > >>IRON routers lease portions of their VPs as Provider > >>Independent (PI) prefixes for customer equipment (CEs), > >>thereby creating a sustaining business model. CEs that lease > >>PI prefixes propagate address mapping(s) throughout their > >>attached RANGER networks and up to VP-owning IRON router(s) > >>through periodic transmission of "bubbles" with authenticating > >>and PI prefix information. Routers in RANGER networks and IRON > >>routers that receive and forward the bubbles securely install > >>PI prefixes in their FIBs, but do not inject them into the RIB. > >> > >> I have a rough idea of what you are trying to achieve with this > >> mechanism, but I have no idea what the mechanism is - "bubbles" > >> doesn't give me any understanding of exactly how the IRON routers > >> would do this securely. Only when I understand exactly how they > >> would do this could I estimate the scaling and security problems > >> which are no-doubt involved. > > > > I have been using the term "bubbles" to keep this at a > > high level and to avoid getting bound up into talking > > about specific mechanisms. But, it sounds like you want > > to know more about the specifics, so I can tell you that > > a "bubble" is actually an IPv6 Router Advertisement (or > > moral equivalent) using the RFC3971, Section 6.1 > > authorization model. In this model, routers are given > > certificates from a trust anchor which authorizes them > > to act as routers and to advertise a certain set of > > subnet prefixes. Other routers in RANGER use the > > certificates to verify authorization. > > > > The scalability part is addressed in the new text I > > have added to the rebuttal. What we really need to > > avoid is having off-path attackers injecting lots of > > bogus RAs that cause IRON routers to have to perform > > lots of unnecessary crypto. By shutting down off-path > > spoofing, IRON-RANGER ensures that end sites that act > > with integrity will not overload correspondents with > > crypto-busting DoS attacks. End sites that do NOT act > > with integrity on the other hand will be easy to detect > > and can safely be blacklisted. > > I wasn't even thinking about attackers. I don't know anything in > detail about RFC 3971 and I don't think you should require readers to > interpret a document such as this, which has nothing to do with I-R, > in the context of what little they know about I-R - and then to > figure out enough detail about how it would work to convince > themselves that this is scalable. > > To improve on this section of the I-R description, I suggest you > nominate some target numbers for the maximum number of IRON routers > there will ever be, how many individual prefixes of end-user network > "edge" space there could be in total, the maximum number of these > that any one IRON router might need to handle, how many VPs there > would be, how many individual "edge" prefixes there might be in a VP, > how many VP routers there might be per VP prefix, how often each IRON > router will register each of its "edge" prefixes with the one or move > VP routers . . . and then describe in detail how the system works, > with one or more examples. This would enable people to understand in > good physical detail how your system works, without having to read > RFC 3971 and imagine how you would use it in I-R. The reader needs > to be able to estimate the number of packets flowing in the various > roles, the length of the packets, the computational resources > required at each router, the security measures as you mentioned - but > in greater deta
Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks
Robin, > -Original Message- > From: Robin Whittle [mailto:[email protected]] > Sent: Monday, March 08, 2010 10:15 AM > To: RRG > Cc: Templin, Fred L > Subject: IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Hi Fred, > > In "Re: [rrg] Recommendation and what happens next", you wrote: > > > Hi Robin, > > > > About IRON-RANGER below: > > ... > > >> That leaves four CES architectures: > >> > >>IRON-RANGER > >>Ivip > >>LISP > >>TIDR > >> > >> TIDR can't solve the routing scaling problem because its "mapping" is > >> almost identical to advertising individual end-user network prefixes > >> in the DFZ. I have argued that IRON-RANGER is not yet sufficiently > >> developed to understand its security and scaling challenges - and > > > > The points on security and scaling have been addressed > > in my latest rebuttal; see: > > > > http://www.ietf.org/mail-archive/web/rrg/current/msg06158.html > > I don't understand the mechanisms by which potentially very large > numbers of IRON routers repeatedly and continually register with > potentially multiple VP routers. These IRON routers could be > anywhere and so could the VP routers. In that message, the most I > can discern about this mechanism is: > >IRON routers lease portions of their VPs as Provider >Independent (PI) prefixes for customer equipment (CEs), >thereby creating a sustaining business model. CEs that lease >PI prefixes propagate address mapping(s) throughout their >attached RANGER networks and up to VP-owning IRON router(s) >through periodic transmission of "bubbles" with authenticating >and PI prefix information. Routers in RANGER networks and IRON >routers that receive and forward the bubbles securely install >PI prefixes in their FIBs, but do not inject them into the RIB. > > I have a rough idea of what you are trying to achieve with this > mechanism, but I have no idea what the mechanism is - "bubbles" > doesn't give me any understanding of exactly how the IRON routers > would do this securely. Only when I understand exactly how they > would do this could I estimate the scaling and security problems > which are no-doubt involved. I have been using the term "bubbles" to keep this at a high level and to avoid getting bound up into talking about specific mechanisms. But, it sounds like you want to know more about the specifics, so I can tell you that a "bubble" is actually an IPv6 Router Advertisement (or moral equivalent) using the RFC3971, Section 6.1 authorization model. In this model, routers are given certificates from a trust anchor which authorizes them to act as routers and to advertise a certain set of subnet prefixes. Other routers in RANGER use the certificates to verify authorization. The scalability part is addressed in the new text I have added to the rebuttal. What we really need to avoid is having off-path attackers injecting lots of bogus RAs that cause IRON routers to have to perform lots of unnecessary crypto. By shutting down off-path spoofing, IRON-RANGER ensures that end sites that act with integrity will not overload correspondents with crypto-busting DoS attacks. End sites that do NOT act with integrity on the other hand will be easy to detect and can safely be blacklisted. > >> there's no apparent method of supporting packets sent from > >> non-upgraded networks. > > > > Non-upgraded IPv4 networks will continue to work as they > > always have. Do you mean non-upgraded IPv6 networks? > > I mean when you start installing IRON routers, these will collect > packets addressed to "edge" addresses (or whatever the new subset of > "EID" space is called in I-R) Virtual Prefixes (VPs) - but, VPs cover what IRON-RANGER calls Endpoint Interface iDentifier (EID) prefixes. > from the ISP networks they are > installed in. Packets sent by hosts in those networks will be > handled according to I-R principles and the recipient networks of > those packets will get the benefits (portability, multihoming and > inbound TE) for those packets. > > But what of packets sent from hosts without IRON routers? AFAIK, > there's no equivalent in I-R to Ivip's DITRs or LISP's PTRs. Considering for now only IPv6 as EID space, an IPv6 host will be connected to a network that is ultimately served either by an IRON VP or a "native" IPv6 prefix. If an IRON VP, then routing is naturally via the IRON. If a "native" IPv6 prefix (e.g., a 2001::/ derivative), packets will follow default or more-specific routes as usual but will encounter an IRON VP router if the destination is covered by a VP. > > Assuming the latter, let's consider that today we have > > two separate BGP instances - the IPv4 BGP instance and > > the IPv6 BGP instance. The IPv6 BGP instance carries a > > set of IPv6 prefixes (e.g., 2001:: derivatives) that are > > routed in the IPv6 Internet in the "traditional" sense. > > What IRON-RANGER is doing is essentially creating a > > *third* BG
