Hi Dino, You wrote:
>> 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. OK, I now understand LISP ETRs reside at the end-user network, and so can be controlled directly there without the ISPs knowing or caring about them. >> 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 than we encourage > use of SMRs. I just wrote a separate message on how I think the Versioning system would work in circumstances where the Solicit-Map-Request wouldn't. > 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. OK - Ivip doesn't have complexities such as Locator Reachability Bits, Versioning or Solicit-Map-Requests. >> During times of disruption, when they most need to communicate, ETRs >> will often be unable to communicate reliably. I understand now that in LISP this is unlikely to be the case, since the ETRs are supposed to be in the end-user network, not in the ISPs. >> 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. I was trying to keep it brief . . . ISPs and end-user networks can make their own arrangements for ISP-based ETRs forwarding packets to destination networks, including tunnels, dedicated links or whatever. It is beyond the scope of Ivip to say what those should be, but there may well be reasons for standardising some approaches if anything new is needed. In Ivip, the ETR can be anywhere - it does not have to be at the ISP or at the end-user network. The ETR may have no relationship with the access network of the destination network, especially if the destination network is a Mobile Node. The MN's owner may employ a Translating Tunnel Router company to supply TTRs and other services close to wherever they happen to be: http://www.firstpr.com.au/ip/ivip/#mobile The MN makes a two-way encrypted tunnel to a preferably nearby TTR, from wherever it is, including behind one or more layers of NAT. Incoming and outgoing packets traverse the tunnel and the TTR also acts as an ITR for any outgoing packets which need to go to Ivip-mapped micronet addresses. >> 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. The idea is to have some specialised company with a bunch of probing servers distributed around the Net. These work as a team, and according to whatever the end-user network wants, probes reachability of their network by whatever means and frequency they desire. Typically this would be four to eight or whatever globally dispersed probe servers sending a nonce-carrying ping packet to one or more routers or hosts in the end-user network, but first encapsulating (for map-encap) the packet so it goes via one ETR or another. For modified header forwarding, the probe servers also behave like ITRs and convert the packet's header to include the ETR address (IPv4) or enough of the ETR address (IPv6) - so the upgraded DFZ and other routers to forward the packet to one or another of the ETRs. This way, without the ETRs being explicitly involved in probing (they don't have to recognise or respond to probe packets - but they could), their connectivity from various places in the Net and their connectivity to the end-user network can be probed with whatever frequency the end-user network specifies. The end-user network would also typically give a (revocable) mapping control username and password to the reachability probing company so this company could control the mapping of the end-user network's micronets (EIDs) Then the end-user network would give the company instructions on how long to wait, in the even of an apparent outage (detected by probe packets not acknowledged), before changing the mapping to the ETR which does appear to be working, from the one which was being used, but is now no longer reachable from a sufficient number of probe servers for it to be considered not worth using for traffic. In Ivip, the mapping for any one micronet consists of a single ETR address, so the ITRs have no decisions to make and the mapping is simple and short. In principle, this Ivip approach is less finely adaptable to outages which are localised in some parts of the DFZ, than would be the approach used by LISP or any other system where the ITRs individually decide which ETR to use. However, I doubt this will be a show-stopper. It would only be an advantage to LISP, over Ivip, when both ETRs were partially affected, so that each one had a different section of the Net which could not reach it, and when the affected ITRs could figure this out in time. Assuming the mapping of a micronet is currently to ETR A: As long as one of the ETRs (B) is reachable from the entire Net, then as long as the proposed external probing and decision making system indicates this is the case, and also detects that ETR A is partially or completely unreachable from various places in the DFZ, then the mapping will be changed in a few seconds so all ITRs will tunnel packets to ITR A. At times of both ETRs being unreachable from different parts of the Net, I doubt if the average LISP ITR is going to be able to do a significantly better job than a well designed, individually customised, distributed prober company system as I describe. I imagine that situations where neither ETR is reachable from the entire DFZ would be short-lived, since the BGP system will be busy adapting to whatever has happened and will fix it pretty quickly. I don't think any core-edge separation can prevent outages of a few seconds to 30 seconds or whatever. With Ivip, the response time depends on how frequently the probing is done and how twitchy the decision making process is. I think the Ivip system should be able to change the behavior of all currently involved ITRs in a few seconds. I see the purpose of multihoming and the other benefits of the new kind of address space (I call it Scalable PI space) not so much as trying to prevent short glitches, but in recovering quickly from outages which go on for more than 20 seconds, a minute or whatever - and which might go on for hours, including especially technical or business failure in one of the ISPs. > 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). I don't understand how this relates to what I am trying to explain about how with Ivip, the end-user network typically appoints a separate, specialised, company to continually probe its network via how ever many ETRs it has. That probing and the resulting mapping decision making can be customised in any way, by agreement between the probing company and their customer, the end-user network. This is not part of Ivip. So any frequency, any protocol, any number of probing servers in any mix of locations, any decision making algorithm at all can be chosen and finely adapted until the end-user network is happy about the responsiveness to outages and with the frequency of probing. For any network with significant incoming traffic, this burden of probe packets will be far less than whatever probing, or attempts at sending traffic packets, the ITRs of LISP or APT make, since there are potentially thousands of such ITRs sending packets at any one time. You can't rely with LISP or APT on getting any messages to these ITRs about real-time changes in reachability. For one thing, it may not scale to try to send a message to them all. Secondly, you can't easily secure such a message. Thirdly, you can't necessarily piggyback a Solicit-Map-Request on a traffic packet going back to the site with the ITR, since the sending host might not be on an EID address. Also, there could be one-way traffic flows. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
