Hi Robin, Main point is that you have identified an IR(VP) liveness detection issue, but I think I have an idea that might help. See below for more detailed responses:
> -----Original Message----- > From: Robin Whittle [mailto:r...@firstpr.com.au] > Sent: Thursday, March 25, 2010 4:28 AM > To: RRG > Cc: Templin, Fred L > Subject: IRON-RANGER - Single VP->routers file with delta checks > > Short version: The new plan for I-R is to not use BGP or Route > Reflection, but to have all IRON routers download a > multi-megabyte (in a full deployment) file which > lists every Virtual Prefix (VP) and for each VP the > addresses of the 2, 3, 4 etc. IRON routers which > perform the IR(VP) role for this VP. > > Each IRON router would keep this information up-to- > date via delta checks with some central servers. > > This avoids the need for BGP etc. > > I think it is highly scalable, since the number of > VPs will be finite, each VP will cover many EID > prefixes, and since the file only lists the subset > of IRON routers which perform the IR(VP) role. > > This is unique Core-Edge Separation architecture > which avoids excessively long paths for initial > packets (as may occur with LISP-ALT) and which > uses tunneled traffic packets as map requests. > > It avoids the NERD approach of ITRs knowing mapping > for every EID prefix. > > I think it is much superior to LISP-ALT - but that > Ivip would be better still. > > There needs to be a way of tunneling a traffic > packet to an IR(VP) router which has never been > used by the tunneling router before, and finding > out quickly (such as in the next 0.5 to 1.0 seconds > whether the IR(VP) router is alive and ready to > accept such traffic packets. The obvious way to do > this is to await the map reply message. Until > then, I think it cannot be assumed the tunneled > packets are going to be delivered, so perhaps they > should be buffered and sent to an alternative IR(VP) > router if they are not too stale after some time-out > if no mapping arrives from the IR(VP) router. > > Otherwise, every IRON router would need to > continually test reachability to all the IR(VP) > routers - which would be unscalable. > > > Hi Fred, > > I am responding to (msg06342) "Re: [rrg] IRON-RANGER - Route > Reflectors & DNS?" with a new title to reflect your new plan of a > single file to tell all IRON routers which IRON routers are > performing the IR(VP) role for each VP. > > > You wrote: > > > There has been yet a third approach for this, which I > > think really alleviates all of the complexity we have > > been discussing. Since the list of VPs as well as the > > individual VP->RLOC mappings changes only very rarely, > > it should be sufficient for every IRON router to simply > > upload a flat file containing the full mapping table > > from a content server when it boots up. The IRON router > > should probably also check for deltas periodically to > > detect additions and deletions. That's about it. > > OK, I understand this means something like: > > For every VP there are at least 2 and probably 3, 4 or 5 > IRON routers performing the IR(VP) role. Yes. > There is a centrally maintained list of all the VPs and > for each VP, the IP addresses (or FQDNs?) of the IRON > routers which are currently playing the IR(VP) role for > each such VP. > > With 100k VPs, this is, for instance, 400k addresses. > IPv4: 1.6 Mbyte; IPv6: 6.4 Mbyte > In reality, the files would be somewhat bigger than this, > and bigger still if FQDNs were used. Yes. > Each IRON router (say 300k to 600k of them) downloads a copy of > this file and then uses some protocol to check for changes > periodically ("delta check"), somehow keeping its own copy up-to- > date. The frequency of these delta checks and the ability to load > share them amongst multiple generally "nearby" servers will affect > the scaling of the whole system, including how frequently these > delta checks can be performed - once every minute, 10 minutes, or > hour. I was thinking the list of all IRs would be capped off somewhere around 100k or so. As far as I can tell, IRs should be the border routers of large corporations, ISP networks, academic institutions, government agencies, etc. They should not be placed on home user residential gateways, individual airplanes, etc. In other words, the IR(EID)s would be placed in a manner that would be somewhat analogous to the way in which EBGP routers are placed in the Internet DFZ today - and I don't think we have millions and millions of those, right? > I think this is a promising approach, OK. > but . . . There's always a "but" when we talk about these things, isn't there? > When a given IRON router playing the IR(VP) role for a prefix P > ceases doing this, or becomes unreachable, each IRON router needs > to be able to detect this really quickly - otherwise data will be > lost by tunneling a traffic packet to that IR(VP) router. But, how long does it take for BGP peers to detect that a neighbor has gone unreachable? I should think that with SEAL we should be able to get within the same ballpark for unreachability detection. > If the IR(VP) router is unreachable, will SEAL tunneling tell the > IRON router which is tunneling traffic packets to it? (If not, > then there would be ongoing data loss.) If so, would that ITE IRON > router be expected to have buffered the traffic packet so it could > be tunneled to another IR(VP) router instead? If not then there > would be ongoing data-loss. No buffering, but isn't the concern the same as for when a BGP router goes unreachable? There will be a period of data loss in that case too, right? > More on this below. > > When an IRON router adopts the IR(VP) role for a given prefix, > depending on the registration mechanism, it will take it a while > to be sure it has received all the registrations for the EID prefixes > in its VP. Only then can it declare itself open for business - so > only then could its address or FQDN be added to the master list. > (But it the master list is the one which is used for registration - > see below for a solution to this problem.) > > Then it would take time, depending on the speed of delta checks, for > all the IRON routers to know of this IR(VP) role. Right, but adding a new IR(VP) (or adding a new VP to an existing IR(VP)) would be a major event that will take some time to percolate throughout the IRON. This is not something that should happen every few minutes or even hours. > >> I understand that the IR(GW) role is roughly equivalent to that of an > >> Ivip DITR or LISP PTR in that it advertises the full range of I-R > >> "edge" space to neighbouring ASes and so accepts packets sent from > >> any of those networks which have not been upgraded with IRON routers. > >> > >> But see further discussion below where you mention: > >> > >> > IR(GW)s forward data packets from the IRON into the DFZ. > >> > >> > >> In addition, there are the IRON routers which perform none of the > >> above roles, but which advertise the IRON "edge" space in the > >> internal routing system of the AS they are located within, and so > >> accept packets sent from within that AS which are addressed to I-R > >> EID prefixes. I figure any IRON router does this, no matter what > >> other roles it may play. > > > > I think what you are describing here is the same as what > > I meant by IR(EID). > > Your mention of IR(EID) was in msg06329. I quoted that in my > message of this new thread (IRON-RANGER - Route Reflectors & DNS?) > which did not make it to the RRG list, but to which you replied in > msg06342. > > Your description was: > > IR(EID) - an IR that connects a customer EID network > > I understood this role to be an IRON router accepting tunneled > traffic packets whose destination address (once detunneled) matches > that of an I-R EID prefix which this router is accepting packets > for. This router is then able to forward the traffic packets to > the end-user (AKA "enterprise") network whose EID prefix this is. > > You didn't have a name for the role played by an IRON router where > it advertises the totality of the I-R "edge" space in the routing > system of its network (where this IRON router is inside an ISP or > end-user network and not advertising these prefixes to other ASes). > The role of this router is to: > > 1 - If it has no mapping for an EID which covers the destination > address of the packet, to tunnel it to one of the routers > which is playing the IR(VP) role for the VP which covers the > destination address - and then to await "mapping" being sent > back from that IR(VP) router, which it will cache and use to > handle any subsequent traffic packets whose destination > address matches that of the EID in the mapping, as described > in the next point. > > 2 - If it has the mapping for an EID matching the destination > address to use this to choose which IR(EID) role IRON router > (as per my understanding) to tunnel the packet to. > > When these things are done by an IRON router which advertises all > the I-R "edge" space in the DFZ, you call this the IR(GW) role: > > IR(GW) - an IR that connects the IRON to the DFZ > > but you have no name for the role of an IRON router doing the same > things but only accepting traffic packets from its local routing > system. > > I understood that every IRON router did this anyway, so you didn't > have a name for this role. Still, I think there should be a name > for this role, even if all IRON routers are capable of doing it. > In the following discussion, I will give this role a name: > > IR(LF) - forwarding traffic packets which arrive from its local > routing system. > > > So here is my rewrite of the roles, including this one: > > IR(LF) - Forwarding traffic packets which arrive from its local > routing system. Advertises all I-R "edge" space in > its local routing system. > > (All IRON routers are capable of doing this, but it is > still a distinct role.) > > > IR(GW) - Like an IR(LF) role except that the IRON router > advertises the I-R "edge" space in the DFZ (that is: in > the DFZ, to DFZ routers of other ASes but its own). > (This is similar to LISP's Proxy Tunnel Routers and > Ivip's DITRs, though a DITR normally only advertises a > subset of the "edge" space.) > > > IR(VP) - One of typically 2, 3, 4 etc. IRON routers which handles > a given Virtual Prefix of I-R "edge" space. This means > it: > > 1 - Accepts registrations of EID prefixes which fall > within this VP, from the IRON routers which > perform the IR(EID) role for these EID prefixes. > > 2 - Accepts tunneled traffic packets from IRON routers > performing the IR(LF) and IR(GW) functions and > then tunnels the packet to the correct IR(EID) > role router for the EID prefix which covers the > packet's destination address. (This may be the > same router, so no tunneling is required - but > usually it will be another IRON router.) > > 3 - After 2, sends mapping for the matching EID to the > IR(LF) or IR(GW) role router. > > What does it do with a packet which matches its VP, but > for which it has no EID registration? Should it tunnel > it to another IRON router which is also performing the > IR(VP) role for this EID prefix? According to your > reply below, it should not buffer the packet - so it > can't resend any traffic packets to another IR(VP) > router if the first one appears to be dead. If the IR(VP) does not have an EID registration that matches the packet, it should drop the packet. But, more on this below: > IR(EID) - Accepts tunneled packets from IR(VP), IR(LF) and IR(GW) > role routers and then delivers the packet to the > destination network. A multihomed end-user network > will have two or more ISPs and there will be an IR(EID) > role router for each such ISP. (Whether this router is > in the ISP network or in the end-user network is not > fixed, but it is always on a conventional "RLOC" - AKA > "core" address.) I think your definitions are fine for use for the purpose of this discussion, but I'm not convinced yet that there is a need to have IR(LF) in addition to IR(EID). In my way of thinking, all IRs are IR(EID)s even if the EID space aggregated by the IR is NULL. > > We're not going to use BGP over the IRON anymore at all; > > the whole map will be kept in a flat file. > > OK - that saves a lot of trouble! Right, but the tradeoff is that we will not get liveness detection in the control plane so we will need to test liveness in the data plane. > >> So there still needs to be some new mechanism for IRON routers which > >> play the IR(EID) role to register their EID with the typically two or > >> perhaps more IRON routers playing the IR(VP) role for the VP which > >> covers the EID prefix in question. > >> > >> Below, I contemplate using DNS for this purpose - and you made a > >> similar suggestion for IRON-RANGER when discussing Ivip in your > >> recent message. > >> > >> In the new model, I understand that the entire set of IRON routers is > >> split up into clusters, with each cluster having a single IRON router > >> playing the IR(RR) role and all the other IRON routers in the cluster > >> being a client of that IR(RR) role router. > >> > >> However, these clusters need not be within a single AS network, or > >> even be restricted to any part of the Net. > >> > >> You suggest below how you would give each of these client routers the > >> ability to use another IR(RR) in the even that its current one fails. > >> RFC 4456 (Section 7) mentions two or more RR routers in a cluster > >> which work together and which prevent routing loops between them by > >> using a common 4 byte CLUSTER ID. > >> > >> I guess this approach could be used in I-R, if we assume that any > >> given IRON router which is not playing the IR(RR) role will be > >> configured by some means to tunnel to the one set of IR(RR) routers > >> for whichever cluster it is within. > >> > >> However, I think the goal is to make any non-IR(RR) IRON router be > >> able to get best-paths from two or more widely separated IR(RR) > >> routers, which wouldn't I guess be using the same cluster ID. So I > >> think each such client router should not pass on best-paths learned > >> from one IR(RR) router to another. > >> > >> > >>> Then, when each IBR(VP) starts up it likewise resolves the > >>> name "isatapv2.net" and forms a BGP session with one or > >>> a few IR(RR)s that are "nearby" (the IR(VP) can decide > >>> for itself what constitutes "nearby"). The IR(VP)s then > >>> advertise their VPs into the IRON, and the IR(RR)s ensure > >>> that all VPs are reflected to all IR(VP)s. > >> OK - I will assume there is some way the DNS can return dozens or > >> hundreds of IP addresses of all the IRON routers playing the IR(RR) > >> role. That wouldn't fit into a single DNS reply packet - I have not > >> studied how DNS returns more information than would fit into a single > >> packet. I understand that you plan for 50 to 100 IR(RR) routers. > >> > >> I guess a given IRON router playing the IR(VP) role which connects to > >> two separate IRON routers playing IR(RR) roles will act like a client > >> to each one separately, and would not pass on any best paths back to > >> the other IR(RR): > >> > >> > >> IR(RR) [AA]------\ > >> [GG] IR(VP) > >> IR(RR) [BB]------/ > >> > >> See below where this guess about an IRON router GG using two or more > >> Route Reflectors turns out to be valid: > >> > >> > When each IR that needs to form a tunnel with an IR(RR) > >> > comes up, it checks through the list of all IR(RR) IP > >> > addresses and picks one or a few that are "nearby". It > >> > is up to each IR to decide what is "nearby". > >> > >> > >> So GG would be like a client to AA and a client to BB, getting a best > >> path from both AA and BB for each of the VPs. It wouldn't advertise > >> any best paths for VPs other than the ones it was playing the IR(VP) > >> role for. > >> > >> It wouldn't matter that GG it gets two best-paths, one through AA and > >> the other through BB, for each VP other than its own ones, because it > >> is not going to use the paths themselves. It is only using the best > >> paths to find out the IP address of the "nearest" of the two or more > >> IRON routers playing the IR(VP) role for each VP which it is not > >> advertising itself. However, the above arrangement may result in GG > >> getting best-paths for two different routers playing the IR(VP) roles > >> for a given VP. Then it would need to choose one. > >> > >> > >>> After all of the VPs have been disseminated to all of the > >>> IR(VP)s, then the IRON-RANGER data packet forwarding and > >>> route optimization can be coordinated in the forwarding > >>> plane. That's it. > >> But to the above description, I think you would need to add how the > >> IRON routers which are not playing the IR(RR) and IR(VP) roles are > >> brought into the overlay network. These may be ordinary IRON routers > >> with no other roles, or they could be playing the IR(GW) role and/or > >> the IR(EID) role. > >> > >> I guess you could have them look up the full list of IRON routers > >> playing the IR(RR) role and decide which of these was the "closest". > >> > >> There are potentially hundreds of thousands of IRON routers - all but > >> those playing the IR(RR) role - which need to choose a single IR(RR) > >> router as being "closest". I think there may be scaling problems in > >> doing this, since each one might have a hundred or so IR(RR) routers > >> to choose from - but presumably this process is spread out due to not > >> many of these routers being rebooted at any one time. It is > >> probably not essential that the absolute "closest" one be chosen - > >> but we don't want IRON routers in Siberia choosing an IR(RR) router > >> in South Africa. > > > > We won't need this anymore at all if we go with the flat > > file; all IRs will have the full map to all other IRs. > > That is not my understanding of what you wrote earlier: > > > Since the list of VPs as well as the > > individual VP->RLOC mappings changes only very rarely, > > it should be sufficient for every IRON router to simply > > upload a flat file containing the full mapping table > > from a content server when it boots up. > > That file has an entry for each VP, and each entry contains the IP > addresses or FQDNs of the 2, 3, 4 or whatever IRON routers which are > performing the IR(VP) role for that VP. > > This is not a complete list of all IRON routers - it only mentions > IRON routers which perform the IR(VP) role for at least one VP. > > So it is not what you just mentioned: > > > all IRs will have the full map to all other IRs I was thinking that it may be valuable to require all IRs (not just IR(VP)s) to register themselves with the IRON map administrative authority. That way, there is a list of all nodes that are authorized to act as IRs. > That was something BGP achieved - but I don't think you need it. > > If you want to use a single file to identify all IRON routers, this > would be a lot bigger. Ideally, you would have millions of IRON > routers, with most of them performing just the IR(LF) role. Why millions? Why can't we make do with just ~100k or so that are border routers of major enterprise networks as I discussed above? > The > more there are of these, and of IR(GW) routers, the better the > traffic load is shared among them, so the smaller they can be. > > You could also put the IR(LF) function in a sending host, as I do > with Ivip's optional ITR function in the sending host. > > I don't think there is a need for any IRON router, no matter what > role it is playing, to know the address of every other IRON router. > So I think the list of VPs, with the IR(VP) routers for each VP, is > all you need. This is an area where our viewpoints may be diverging just a bit. I am thinking that IRs would be major pieces of equipment at the borders of medium to large-sized enterprise networks, and that those networks would use EID-based routing (possibly using RANGER recursion) internally. Whereas, you seem to believe that pushing the IRs out to the extreme network edges would be desirable. Remember that with RANGER recursion, however, we can have recursive re-encapsulations so that the IRON principles can apply at any level of the recursion. > This is fine for the two purposes: > > 1 - IR(EID) role routers registering their EIDs with the 2, 3, 4 > etc. IR(VP) role routers. OK, but I still would like to think of *all* IRs as IR(EID)s, even if some IRs configure a NULL set of EIDs. > 2 - IR(LF) and IR(GW) routers tunneling traffic packets to one of > the IR(VP) routers for the matching VP. However, the list > doesn't provide any information on which of these is closest, > which ones of them are currently reachable and which of them > have had time since they were added to the list to get all > the EIDs in that VP registered by all the various IR(EID) > role routers which handle those EIDs. All right; I'll accept the IR(LF) and IR(GW) roles as useful for this discussion. > > There will be no need for IR(RR)s. > > OK. > > > > >>>> I don't think any IRON routers need to know what prefixes are > >>>> advertised in the DFZ, since they don't forward packets to DFZ routers. > >>> > >>> IR(GW)s forward data packets from the IRON into the DFZ. > >> > >> I don't understand this at all. My understanding of the IR(GW) role > >> is to advertise the I-R "edge" space in the DFZ and so attract > >> packets sent from networks without IRON routers, where those packets' > >> destination addresses match any of the I-R EID prefixes. > > > > That's correct; I meant to say: "IR(GW)s forward data packets > > between the IRON and the DFZ.". > > This still doesn't imply a direction, yet they only take packets > from the DFZ and tunnel them to IRON routers, which are playing the > IR(VP) or IR(EID) roles. My previous description makes this clear. See more below: > >> I don't see any need for an IR(GW) router, or any other IRON router, > >> to accept packets from the "IRON" network and to forward them to > >> non-IRON routers of other ASes. > > > > If the packet originates from an IRON network and is > > destined for a non-IRON end system, it will need to > > be forwarded by an IR(GW). > > I don't see how this would occur. If some ISP or end-user network > is using I-R "edge" space, it must have one or more IRON routers in > its own network or in the networks of its ISPs, which are > performing the IR(EID) role. > > When a host in this network sends out a packet addressed to an EID > address, it will be forwarded to one of these IRON routers, which > in its IR(LF) role (which I understand every IRON router performs) > is advertising prefixes covering all I-R "edge" space. That IRON > router will tunnel the packet either to the correct router > performing the IR(EID) role for the matching EID prefix, or it will > tunnel it to one of the routers playing the IR(VP) role for the > matching VP. > > However, when a host sends a packet to an ordinary address outside > the network - not within the I-R "edge" subset of the global > unicast address space, this may go through the same IRON router as > just discussed which is performing an IR(LF) role, but that role > does not affect packets addressed to ordinary global unicast > addresses. So the IRON system is only for carrying packets > addressed to I-R "edge" (EID) addresses. That packet, with an > ordinary destination address, would be forwarded as it is today, > out to the ISP's BR and then to other DFZ routers and eventually to > the ISP or end-user network where the destination host is located. > > > >> As far as I know, all IRON routers are connected to the Internet, so > >> if they have a packet to send to any global unicast address which is > >> not part of the I-R "edge" subset, they do so using their ordinary > >> forwarding techniques. > > > > All IRON routers are connected to the IPv4 Internet, yes. > > But, not all will necessarily connect to the IPv6 Internet. > > So, there will need to be a set of IRs that provide a > > default route to the IPv6 Internet - right? > > IPv4 hosts can't send packets to IPv6 addresses, so I guess you > must be referring to IPv6 hosts sending packets to IPv6 addresses > which are either IR "edge" addresses or not - and that the network > these hosts are in is an island IPv6 network, without native IPv6 > connectivity, but have IRON routers which are somehow linking this > IPv6 network to the real IPv6 Internet. I won't speculate on how > this could be done. All right. So, this means that if we want to stand up IRs that use IPv6 EIDs then those IRs must be able to connect to the global IPv6 Internet and not just the global IPv4 Internet, right? I don't know enough about this, but I think that the IPv6 Internet is not all that big yet, and that not all enterprises, sites, etc connect to it yet. So, I don't know what sorts of special arrangements would be necessary in order for an IR to get connected. > >> As far as I know, no traffic packets actually traverse the I-R > >> overlay network as such, in terms of going from one IRON router to > >> another via multiple other IRON routers - since whenever an IRON > >> router (either playing the IR(VP) or IR(GW) roles, or playing no such > >> role and just handling a packet which arrived from its local routing > >> system) needs to get a traffic packet to some other IRON router > >> (playing the IR(VP) or IR(EID) roles) then it simply uses SEAL to > >> tunnel the packet directly to the destination router, via the Internet. > > > > Right. I consider the act of using SEAL to tunnel the > > packet directly to the destination router as "traversing > > the IRON". Consider that there is a virtual full mesh of > > tunnels between all IRs, but that most of the time the > > vast majority of tunnels are dormant and not represented > > in soft state. It is this virtual full mesh that I > > consider to be "The IRON". > > OK. > > However, there is no need for every IRON router to know the address > of every other IRON router. They need to know, for each VP, the > addresses of the IRON routers which play the IR(VP) role, and once > they have mapping for particular VPs, this tells them the addresses > of the one or more IRON routers which are playing the IR(EID) role > for this EID prefix. Then they use SEAL to tunnel to these other > IRON routers. I was thinking of having each IR discover the list of all IRs for access control purposes. Again, in my view there should never be more than about ~100k total IRs (both VP and non-VP). > You could refer to this as a virtual full-mesh, but in fact, the > ITEs (ingress tunnel endpoints), but there are never tunnels > between two IRON routers which only perform the IR(LF) or IR(GW) > roles. There are no tunnels btw IR(LF)s initially, but they will be created on demand following a mapping update. > >> For the "forwarding plane" - when the packet is a traffic packet - > >> the ETE is either: > >> > >> 1 - An IRON router playing the IR(VP) role. If it is also > >> playing the IR(EID) role for the destination EID prefix, > >> it delivers the packet directly to the destination network. > >> If not (which would typically be the case) it tunnels it to an > >> IRON router which is playing the IR(EID) role. (In both cases > >> it also sends a "route redirection" packet to the ITE IRON > >> router, to give it "mapping" so that ITE router will be able > >> to tunnel other traffic packets for the same destination EID > >> prefix directly to the proper IR(EID) router.) > >> > >> 2 - An IRON router playing the IR(EID) role for the destination > >> EID prefix. This delivers the packet directly to the > >> destination network. > >> > >> So I can't see any instance where an IRON router delivers a traffic > >> packet "to the DFZ" - that is, to any ordinary Internet router of > >> another AS. > >> > >> I see three types of packet being sent in tunnels between IRON routers: > >> > >> 1 - BGP messages, always between the two tunnel endpoints. > > Not needed now. > > >> 2 - Traffic packets as just mentioned. > >> > >> 3 - Route redirection packets with "mapping" as just mentioned. > >> > >> There may also be some SEAL things I have forgotten. But in all > >> cases, for an IRON router to send a packet to another IRON router, it > >> tunnels with SEAL through the Internet. > > > > Yes. > > OK. > > > > >>>> I predict the vast majority of IPv4 micronets (EID prefixes for LISP > >>>> and I-R) will be less than 256 IPv4 addresses. If you look at the > >>>> huge preponderance of /24 currently advertised in the DFZ: > >>>> > >>>> http://bgp.potaroo.net/as2.0/bgp-active.html > >>>> > >>>> /19 18191 5.74% > >>>> /20 22214 7.00% > >>>> /21 22356 7.05% > >>>> /22 28914 9.12% > >>>> /23 28732 9.06% > >>>> /24 166028 52.35% > >>>> > >>>> I conclude that the great majority of end-user networks find 256 IP > >>>> addresses sufficient. Since this is the smallest number of addresses > >>>> they can advertise in the DFZ (and have the best-paths propagated > >>>> through the whole DFZ) I believe it is reasonable to assume that many > >>>> would be happy with 128 addresses, 64, 32 or whatever. Perhaps quite > >>>> a few would be happy with 1 or 4 addresses. > >>>> > >>>> At present, these /24s only take up a fraction of a percent of the > >>>> IPv4 advertised address space, so arguably they are not wasting much > >>>> space now, by being forced to be 256 addresses when less would suit > >>>> the needs of the advertising networks. However, a good scalable > >>>> routing solution will be catering to many more end-user networks than > >>>> those which currently advertise their own prefixes in the DFZ. > >>>> Assuming the new kind of "scalable" "edge" space of LISP, Ivip or I-R > >>>> has few or no performance problems, then it could be widely used and > >>>> be used in just the right quantities required, without wasting much > >>>> space. > >>> > >>> All right. I think I understand the concept of IPv4 > >>> micronets now. IRON-RANGER can handle this too. > >> > >> OK - I understand you mean that I-R will be able to use smallish > >> chunks of IPv4 space, separately mapped to wherever they are needed, > >> to help with using IPv4 space efficiently - without burdening the DFZ > >> control plane with a prefix for each one, and without wasting space > >> in BGP advertised prefixes which are at least 256 IPv4 addresses long. > > > > Right. > > OK. > > >> Do you also mean that I-R would allow separately mapped portions of > >> IPv4 address space to start and end on integer boundaries, as with > >> Ivip - rather than retaining the conventional binary boundary prefix > >> method of delineating address space? > > > > You mean like have a "prefix" that starts with something > > like 192.0.2.9 and ends with 192.0.2.35? That just seems > > to weird for me to contemplate at the moment. > > OK - its not a prefix, of course - so I call it a "micronet". > > In Ivip micronets are integer numbers of IPv4 addresses or IPv6 > /64s, with arbitrary start and end points - but a micronet is > always within a MAB (Mapped Address Block - a prefix advertised in > the DFZ by DITRs). It is an interesting idea, but for now I'd prefer to stick with powers-of-two prefix lengths. > > VRRP - if used - would be a local system to each site, yes. > > OK. > > > >> For the second purpose, I think BGP won't work. However, since any > >> one IRON router playing the IR(EID) role only needs to know the IP > >> addresses of all the IR(VP) routers for a small subset of VPs, I > >> suggest that DNS would be a perfectly good way they could discover this. > >> > >> It wouldn't matter much if a cached DNS entry pointed to an IRON > >> router which previously performed the IR(VP) role for the VP in > >> question, but had recently died or become unreachable - since > >> registration would proceed with the others. > >> > >> The trick would be to allow a router to come up in an IR(VP) role and > >> make sure it had registrations from all the thousands or hundreds of > >> thousands or whatever IR(EID) role routers before it advertised the > >> VP on the I-R overlay network. To do that via DNS in, say, 5 > >> minutes, would require all the DNS caching times for this lookup > >> process be 5 minutes or less. > > > > No DNS. > > > >> Alternatively, a newly started IR(VP) router which hadn't yet been > >> found by all the IR(EID) routers could advertise itself, but would > >> then need to have a way of handling traffic packets tunneled to it, > >> but for which it did not know any IR(EID) router to forward them to. > >> The most obvious approach would be to forward it to one of the other > >> IRON routers which are playing the IR(VP) role for the same VP, with > >> that one doing the "route redirection" secured "mapping" reply to the > >> IRON router which tunneled the packet, so in the future it would > >> tunnel such packets directly to the correct IR(EID) router. > > > > No, all IR(VP)s that own the same VP will check > > their FIBs to find a more-specific route to an > > EID prefix taken from the VP. If there is no entry > > in the FIB, the packet is dropped. > > OK. > > But here's a problem with the currently proposed scheme, in which > the one file tells all IRON routers about each VP and for each VP > the 2, 3, 4 etc. IRON routers which are performing the IR(VP) > function for the VP. > > This is fine for IR(EID) role routers finding out the addresses of > the 2, 3, 4 etc IR(VP) routers to register their EID with. > > What is not OK is using this file alone for IR(LF) and IR(GW) > routers to decide which IR(VP) routers to tunnel traffic packets to. > > This is because when you make some IRON router NN take on the > IR(VP) role for some VP "P", it will take time (at least the delta > check repeat time, and then some) for all IR(EID) routers to be > able to register with these IR(VP) routers. > > Yet, at the same time, IR(LF) and IF(GW) routers are using the very > same list and may tunnel traffic packets to NN the moment they see > it appear on the list. > > The solution is probably to fix a time for delta checks, such as 10 > minutes, add a fudge factor and then arrive at a time such as 15 > minutes after NN is mentioned as having an IR(VP) role for "P", that > all P's IR(EID) routers will have registered with NN. Then add an > algorithm in the IR(LF) and IR(GW) routers to make them wait for 15 > minutes after they see NN has this IR(VP) role before actually > tunneling any traffic packets to it. Using an idea I will propose below, this may not be necessary. > > This means that if an IR loses its memory there will > > be a lag time until the EID prefix mappings are > > re-established. So, the IR should probably keep > > EID mappings in non-volatile storage across reboots. > > This would make sense for direct reboots, but if the router was > turned off for a long time, or was not able to keep itself updated > due to being unreachable for a long period of time, the delta check > process could lead to so many updates that it would be better to > start afresh and download the full copy of the latest file. Good point. > >> One might think of using DNS instead of BGP for the first purpose, > >> but that would involve some problems: > >> > >> 1 - Each IRON router would need to repeatedly query the DNS for > >> each of the million or so VPs - which is a serious and > >> probably unacceptable scaling problem. > > > > Right - let's not do that. > > OK. > > > >> 2 - If they did this, then it would sometimes try to tunnel > >> traffic packets to and IR(VP) role router which was alive > >> when it last queried the DNS, but has since died. This would > >> cause lost traffic packets, or require some two-way > >> acknowledgement so the IRON router could quickly detect the fact > >> that this supposed IR(VP) router was no longer reachable, alive > >> and still performing this role. While the I-R system involves > >> that IR(VP) router normally sending a "route redirect" AKA > >> "mapping" packet to this router, the only way of making this > >> work as an acknowledgement for the purpose of avoiding lost > >> traffic packets due to a dead IR(VP) router would be the > >> initial IRON router buffering these traffic packets for a few > >> seconds so it could resend them to some other IR(VP) router > >> instead. This would be costly and is not anticipated in the > >> current design. > > > > No buffering of packets. Route failures are detected through > > neighbor unreachability detection, and a different neighbor > > is tried. > > But if some router AA performing the IR(LF) or IR(GW) role has a > traffic packet to tunnel to router XX which is performing the IR(VP) > role, and it has never had any relationship with XX before, there > is no SEAL tunnel in place. > > SEAL would tunnel the packet without any preliminaries, as far as I > know - if there are preliminaries, then this will delay the > delivery of initial packets in a new communications flow. > > The SEAL layer on AA has no idea whether XX is alive. > > If AA tunnels the traffic packet without any buffering, and XX is > dead, unreachable, not playing the IR(VP) role, or if it is playing > the role but for some reason has not received a registration from > any of the IR(EID) role routers, then the packet will be lost > forever. > > There isn't any "neighbour unreachability" since to AA, XX is just > some IRON IR(VP) router it has an address for. It has no > established tunnel and no way of knowing whether it is alive or > dead, unless it either: > > 1 - Performs preliminary handshakes, which would be expensive and > would unacceptably delay traffic packets. > > or > > 2 - Buffers the traffic packet and any other packets it sends to > XX until it gets a mapping packet from XX, which confirms that > at least one of these packets got to XX and that XX is able > to handle them. If, after a second or so, it didn't get > any mapping from XX, then it would assume that XX was dead and > could try sending them to another IR(VP) router - but by then > the traffic packets are getting a bit long in the tooth. > > At present I think this is an unsolved problem: how the IR(LF) or > IR(GW) router detecting the fact that a listed IR(VP) router is in > fact dead or unreachable, especially when it is just about to > tunnel a traffic packet to this IR(VP) router for the first time. The idea is this. When an IR(LF/GW) has a packet to send, but the only thing it has in its FIB is a VP, it sends a replicated copy of the data packet to *each IR(VP) that is listed for the VP in the map*. Each IR(VP) that gets the data packet will forward it onwards to the final destination and send back a mapping reply. So, the IR(LF/GW) will intentionally duplicate initial packets until it gets a map reply back from an IR(VP). The IR(LF/GW) then begins tunneling packets through the route optimized path instead of through the IR(VP). Note that when the IR(LF/GW) receives a map reply, the map reply may list multiple RLOCs - perhaps 2, 3, 4, etc. For robustness purposes, the IR(LF/GW) may then also send duplicate packets through all of the RLOCs until the closest one send back a SEAL acknowledgement (at which point it can cease the packet duplication). > > I think its time to start wrapping this up. Let's try to > > be brief for any additional follow up. > > > > Thanks - Fred > > OK. We have gotten away from the discussion of whether there is a way to tell whether an IR is authorized to forward packets over the IRON using a given EID prefix. Using SEAL, we can tell whether a packet has come from an on-path ITR as opposed to an off path attacker that uses spoofed RLOC addresses, but that still does not tell whether the ITR is authorized to send from a given EID prefix. But, this is why I advocate placing all IRs in the IRON map - so, if one of the registered IRs starts sending packets with spoofed EID addresses, it can be reported to the authorities and punished for its uncivil behavior. What do you think? Thanks - Fred fred.l.temp...@boeing.com > - Robin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
