With LISP, I have no idea how the ETRs of a particular end-user
network are supposed to coordinate their activities so as to be able
to do anything consistent or reliable regarding telling ITRs which
ETRs are currently reachable, or at least which are reachable from
the DFZ and are also connected well (not congested) to the
destination network.
They are configured the same way.
These ETRs are going to be in different ISPs, so how are the ISPs
supposed to configure their ETR to communicate reliably and securely
with ETRs in some other ISP, for every single end-user network which
uses that ETR?
ETRs reside at sites. The IGP helps each of them determine the up/down
status of the routers.
When things are getting rough, with outages, traffic flowing in
different ways to get around the outage, congestion, misconfiguration
etc. how are the ETRs supposed to communicate reliably to work
consistently together?
There is no solution to this today with existing protocols. But you
have to think about a network that is designed that would cause a site
to completely partition. That is typically known as a dumbbell
topology. Where there is a lot of redundant topology on each side of
the dumbbell but for some reason there is only a single set of links
connecting both ends.
No one would design a dumbbell topology and haven't seen one for about
15 years. So we have to choose what failure cases we want to solve and
which ones we should leave alone.
How are they supposed to decide what the real reachability situation
is? Likewise the mapping information? There might be three ETRs in
different ISPs, each in some way configured by one or more ISPs
and/or in some way controlled by the end-user network in terms of the
mapping information they send out to the APT network (or register
with their respective Map Servers which do this).
But what if ETR-A becomes isolated from the end-user network? The
end-user network might configure (or ask its ISPs to configure) the
other two - ETR-B and ETR-C - with some different mapping
information, such as new RLOCs, deleted RLOCs or rearranged RLOCs.
But ETR-A will not have this new configuration and so will be causing
different mapping and/or different locator reachability bits to be
sent out via the ALT network or to ITRs.
Versioning may be more secure than the ETR sending locator
reachability bits, and it may involve the ETR in less complexity.
However, I think the whole business of involving ETRs in matters
concerning reachability and mapping is a problem for LISP.
Versioning creates the opportunity of having to keep many sets of
mappings. Plus the spec encourages use of it more so then we encourage
use of SMRs. So I would conclude that there could be more cases and
more complexity with versioning. We did consider versioning and
realized we'd have to probably implement similar mechanisms as how BGP
uses versioning for it's RIB.
During times of disruption, when they most need to communicate, ETRs
will often be unable to communicate reliably.
In Ivip, ETRs do two things:
1 - For encapsulation: Decapsulate packets
Modified header forwarding: Restore original IP headers
Then the ETR forwards the packets to the destination network
by some locally configured means.
With all due respect Robin, this description lacks any details to
allow me to believe you solved the problem.
ETRs might be involved in probing of reachability, by whatever
external system the end-user network hires (or deploys themselves).
Probing just doesn't scale for the scale of any-to-any connectivity we
have planned.
Let me put it this way. Just think about a Google DNS server having to
probe every system that has ever sent it a DNS query. And when you
have to probe that many systems from many different places, the only
way you can scale it is temporally. And when you do that, the
usefulness of switchover is lost (takes too long).
Dino
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
