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.
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.
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 think this is a promising approach, but . . .
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.
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.
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.
>> 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.
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.)
> 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!
>> 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
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. 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 fine for the two purposes:
1 - IR(EID) role routers registering their EIDs with the 2, 3, 4
etc. IR(VP) role routers.
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.
> 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.
>> 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.
>> 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.
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.
>> 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).
> 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.
> 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.
>> 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.
> I think its time to start wrapping this up. Let's try to
> be brief for any additional follow up.
>
> Thanks - Fred
OK.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
