1 hour and 40 minutes before the RRG meeting at IETF 77:
Short version: Fred envisages IRON routers being relatively big
and few in number - say 100k or so in total.
I suggest that there should be numerous IR(LF)
role routers (the equivalent of an ITR) to
spread the load of this work, and do this
closer to sending hosts.
Fred proposes a solution to the problem I raised
of tunneling a packet to an IR(VP) role router
which may be dead or unreachable, or unable to
handle the packet. Fred suggests tunneling the
packet (these are "initial" packets only) to
all the IR(VP) role routers, which would be 2, 3,
4 or so. This seems like a good solid solution
to me, as long as the potential duplication of
packets at the destination network can be handled
in some way. Also, this multiplies the workload
of all the IR(VP) role routers in proportion to
how many there are of them - compared with
load-sharing between then and sending just one
copy of the traffic packet to one IR(VP) role
router.
Hi Fred,
You wrote:
> 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:
>> For every VP there are at least 2 and probably 3, 4 or 5
>> IRON routers performing the IR(VP) role.
>
> Yes.
OK.
>> 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.
OK.
>> 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?
This may be OK for some or many of the IRON routers performing
the IR(EID) role, which to my understanding means delivering
packets to EID-using end-user networks. This is separate from
the IR(LF) role I invented, which is accepting packets from the
local routing system which are addressed to I-R EID prefixes and
then tunneling those packets.
I think there should be lots of these IR(LF) role routers - the
more there are the less load there is on each one, and so the
cheaper they can be. This includes putting the function in
sending hosts and all manner of "routers".
>> I think this is a promising approach,
>
> OK.
>
>> but . . .
>
> There's always a "but" when we talk about these things,
> isn't there?
This field is full of "gotchas"! Better to find out about them
sooner rather than later.
>> 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.
The IRON router playing an IR(VP) role will be located on some
piece of address space which is advertised in the DFZ. However
there are other reasons why this router could be unavailable
beyond what would be detected by BGP. BGP would only detect the
whole route to that prefix being unreachable. This could be
fine, but the router itself might be dead, being rebooted etc.
Or the router might not be performing this role - or it might be
performing it, but hasn't yet got all its EIDs registered, in
which case it can't handle all the traffic packets which might
be sent to it.
>> 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?
As noted above, I think that BGP in the DFZ detecting a prefix
advertised from a BR is now unreachable is not sufficient to tell
any IRON router whether it should or should not try to tunnel to
some IRON router in that prefix which is listed (in the centrally
controlled file) as playing the IR(VP) role for some VP.
>> 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 agree, but there needs to be a way of dealing with it happening
without traffic packets being sent to it when it suddenly dies,
or when it is listed as performing this role, but is not yet
ready to do so.
>> 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:
OK.
>> 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.
OK - all IRON routers are capable of performing the roles I
describe as IR(LF) and IR(EID). Still, I think, for discussion,
it is important to be able to identify these roles with a simple
term.
>>> 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.
OK.
>> 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.
OK - but the complete set of IRON routers is much larger than the
subset which perform IR(VP) roles, so the file would be larger.
I am not convinced you need each IRON router to have the address
of every other IRON router.
I prefer the idea of anyone being able to perform IR(LF)
functions on their own servers or routers, without having to
register the device in some central database.
Generally, the more there are of these IR(LF) functions, the
closer they are to sending hosts, the less work each one has to
do and the less subject each one will be to congestion, needing
large caches etc.
>> 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?
As I just argued - the more devices which perform the "ITR"
function the better - with people being able to run them without
needing permission, on their own hardware.
Doing this ITR = IR(LF) role is work. A major goal with Ivip and
I think LISP is to make it easy for people to run their own ITR
functions, closer to the sending hosts and for Ivip, inside the
sending hosts if this is locally desired. In a sending host, the
cost can be zero in terms of capital, software, extra power,
extra space etc.
>> 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.
There is a definite divergence here. My only interest in IRON-
RANGER is as a scalable routing system. I know it descends from
a broad-scope RANGER system, which did far more things than I
thought were interesting, including interlinking IPv4 and IPv6
in some way, and various "recursive" things I couldn't see the
need for.
>> 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.
Sure - all IRON routers are capable of performing the IR(EID)
role, but only a subset do. So it makes sense to have a term for
this role.
>> 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.
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:
OK.
>>>> 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.
I am not sure what you are planning regarding this notion of IPv6
sites using IPv4 for all their connectivity, and I don't yet
understand what you meant by:
>>> So, there will need to be a set of IRs that provide a
>>> default route to the IPv6 Internet - right?
>>>> 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).
OK.
>> 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.
OK.
>> 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.
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.
OK.
>>> 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.
OK.
>>> 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).
This sounds like a good approach.
It might be subject to critiques about the fan-out of packets to
up to 5 or so VPs being a DoS amplifier of some kind.
However, as long as there are not too many IRON routers playing
the IR(VP) role for each VP, then this will be a reasonably good
arrangement.
We want multiple IR(VP) routers for robustness. However whatever
the number is, say 4, this quadruples the incoming load of each
such IR(VP) role router.
Also, for these initial packets, it will cause 4 times as many
packets to arrive at the one or more IR(EID) role routers.
Some of the 4 IR(VP) role routers might send to IR(EID) role
router EE and some to another such router FF.
You would need to have some kind of system in EE and in FF to
discard second and subsequent packets, since they should not be
sent to the end-user network, but I can't see a way that EE and
FF could coordinate this. So there would be cases where EE
forwards its first of 1, 2 or 3 copies of the packet to the
destination network and when FF forwards the first of its 3, 2 or
1 copies of the same packet.
Duplicate packets packets could confuse applications. They may
not be disastrous, but it would depend on the application.
Would it be relatively easy for a single IR(EID) role router to
discard duplicates of the same packet? They are tunnelled from
separate IR(VP) role routers, and the decapsulated packets would
look identical. However, what if the sending host sent multiple
such packets? That would appear the same, if by chance they
came first via different IR(VP) routers. Then, the IR(EID) role
router should not be regarding them as duplicates.
router
> 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?
I can't imagine how you could securely and scalably ensure that
each IR(LF) or IR(GW) role router was handling packets whose
source address matched some allowed subset of the address space,
which would be different for each such IR(LF) or IR(GW) role
router.
Nor do I see how this is important or required to make IRON-
RANGER work.
You have however suggested a solution to the problem I mentioned
- of an IR(LF) or IR(GW) router sending a packet to an IRON
router which was listed as performing the IR(VP) role, but was
either not performing it, or was not reachable at that time. I
suggested buffering, awaiting a mapping reply and then, if no
mapping reply arrives, timing out and sending the buffered
packet to another IR(VP) role router instead. But as I
acknowledged, by then, the traffic packet would be about a
second old - which is probably too old to be useful.
The "scattergun" approach of sending it to all IR(VP) routers
raises some moderate difficulties with increasing the load
on IR(VP) role routers, and with duplicate packets - but I
think it is in principle a good, solid, solution.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
