Hi Bill, Thanks for your response on 24 November:
http://www.irtf.org/pipermail/rrg/2008-November/000261.html I will concentrate on the text in the current 5th draft. The paragraph directly after "Strategy A." is applicable to Ivip. A1a. This doesn't seem to apply to any proposal I know of. A1b. This applies to Ivip and I guess to LISP, APT and TRRP. A1c. I don't clearly understand this. A2a. LISP NERD. A2b. This somewhat applies to Ivip, which is why I suggested: >> A2d. GUIDs dynamically mapped to each RLOC are pushed towards a >> central or distributed registry as they change. The registry >> pushes all incremental changes in near-real time to all >> full database query servers in ISP and/or end-user networks. >> The encoders (ITRs) request mapping from these local >> query servers. The response has a caching time and the >> local query server will push any changed mapping to an >> encoder if it receives such a change for mapping which >> matches a recent query which is still within its caching >> time. There may be one or more full database query >> servers in each ISP and there may be one or more layers of >> caching query servers between these and the encoders. You responded: > Hi Robin, > > When I read this, I see A2b in the large with some local > optimizations. Let me ask others on the group to offer an opinion on > this: is Robin's hybrid method described above distinctive enough from > the other three mapping methods that it should be listed separately in > the document? There being no feedback to the contrary, as the Ivip designer I assert that A2d. above is necessary to properly represent Ivip's fast hybrid push/pull mapping system. I don't think A2b. matches an existing proposal. It is fast, real-time, push to every ITR. No-one is suggesting that this would scale well. So I would be happy if the text above replaced A2b. A2c. I think this matches LISP ALT and TRRP. # Failure handling approaches include: # # Link failures in the Internet core cause the RLOCs to be rerouted # with no change to the address-RLOC map. OK - this applies to Ivip, as well as to LISP, APT and TRRP. A3a. I think this describes the approach of LISP, ALT and I guess TRRP to reachability testing and multihoming service restoration. It involves the ITRs ("RLOC encoders") having multiple RLOCs to choose between, doing their own reachability testing and making their own decisions about which RLOC to use. The previous A3b didn't suit Ivip, so I suggested: >> A3c. End-user networks are responsible for controlling the >> mapping of their EID address space. Each EID prefix - >> in the case of Ivip, not necessarily a prefix, since it >> can be one or more contiguous IPv4 addresses or IPv6 >> /64s - is mapped to a single RLOC address. For reasons >> such as a link failure, to implement inbound Traffic >> Engineering, or to implement address portability when >> moving to another ISP, the end-user network causes >> the mapping to change to the new RLOC address, and this >> is conveyed to all full database query servers in >> near real time. These push the changes to any encoders >> (ITRs) which may need them, based on previous queries and >> the caching times of the responses. > > This is really what A3b is all about. > > I'll adjust it to: > > A3b. Link failures which prevent parts of the RLOC's network from > reaching a destination host or set of hosts it serves cause an > external analysis element to make a dynamic change to the address-RLOC > map, depreferencing or removing the affected RLOC. > > Better? It doesn't really describe Ivip's approach in sufficient detail. There is no "deprefencing" of an RLOC, since Ivip only has one RLOC in the mapping. With a real-time hybrid push/pull mapping distribution system, there is no reason to have multiple RLOCs and the ITR choosing between them for multihoming. This raises questions in the reader's mind about how TE is achieved, which is what my suggested text also describes. Here is another attempt. I think it is a bad idea to avoid mention of ITRs and the name of the proposal etc. but I am trying to follow this style. A3b. End-user networks are responsible for controlling the mapping of their EID address space. Each EID prefix (or non-prefix, contiguous, range of address space: one or more contiguous IPv4 IPv6 /64s) is mapped to a single RLOC address. For reasons such as a link failure, to implement inbound Traffic Engineering, or to implement address portability when moving to another ISP, the end-user network causes the mapping to change to the new RLOC address, and this is conveyed to all full database query servers in near real time. These push the changes to any RLOC encoders which may need them, based on previous queries and the caching times of the responses. >> On second thoughts, A4d is not a good description at all. >> >> A4f. The encoder encapsulates all packets which are short enough >> that once encapsulated, they will be no longer than some >> constant N, where it is assured that the MTU between all >> encoders (ITRs) and ETRs is at least N. Longer packets >> are either encapsulated and sent, or rejected with a >> packet too big message, depending on how their length >> if encapsulated, compares to two variables the encoder >> maintains for each particular RLOC (ETR) address. The >> encapsulated packets function as probes, and depending >> on whether the encoder receives PTBs for them, it >> adjusts its two variables. These represent the >> encoders upper and lower limits to its uncertainty about >> the true MTU to this RLOC. > > I think you were right the first time: this is a fancy version of A4d > but architecturally its still A4d. OK, the current A4d is a terse description. Folks will need to refer to http://www.firstpr.com.au/ip/ivip/pmtud-frag/ to see how Ivip does this. I think no other proposal currently incorporates proper handling of the PMTUD problems caused by encapsulation. >> A4h For IPv6, all DFZ routers are upgraded to recognise an >> alternative format of the IPv6 header in which 19 or >> 20 bits are used to determine the packet's forwarding. >> These bits map to a predefined set of advertised prefixes >> of ISP networks, and so the packet is delivered across the >> DFZ, to a border router of the correct ISP network, without >> PMTUD problems. If there is more than one ETR at that >> network, a second lookup will be required and a similar, or >> different, mechanism internal to the ISP network will be >> required to forward the packet to the correct ETR. > > Whoops, I missed that one. How about: > > A4f. The IPv6 flow label or some other component(s) of the IPv6 header > are used to contain the RLOC. The flow label is set before the packet > enters the core. Non-local packets are routed based on the flow label. > IPv4 is abandoned. This, your current A4f, doesn't describe Ivip's Prefix Label Forwarding at all: http://www.firstpr.com.au/ip/ivip/ivip6/ There is no concept of abandoning IPv4 in this. The full RLOC can't fit in the IPv6 header, but 19 bits of it can, which is sufficient to forward the packet across the DFZ. I would appreciate it if you replaced the current A4f with the text above, converting "ITR" and "ETR" into other terms, if you like. > A4g. Steal bits from other functions in the IPv4 header (e.g. > checksum) to make space for an RLOC. Discard those components and set > the RLOC when the packet enters the core. Restore the original bits > when the packet leaves the core. Use another strategy for IPv6. That is OK if you want to keep it so terse that it is only a cursory explanation. Ideally, people would know this means: ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw It is somewhat more complex than this, since there are 30 bits available, rather than 32, and the system does not handle fragments, or DF=0 packets longer than some TBD length. >> I think it would be helpful to include pointers to actual proposals. >> I understand you want to use a more generalised language to describe >> the various proposals, but for the benefit of anyone who is not >> totally up with RRG discussions (or who is, but is tired), I think it >> would help to have such pointers. > > I'm trying to keep this document higher level than that. I think a > second document which maps from the strategies to the proposals and > vice versa would be very helpful. OK - When it is finalised I will write a message trying map your descriptions to the proposals as best I can. Regarding your assessment of the Strategy A: # Major criticisms: # # There don't appear to be any genuinely clean ways of implementing # strategy A. "Genuinely clean" could mean almost anything. A major characteristic of Strategy A your page doesn't mention is that it can be introduced smoothly, without requiring changes in hosts. With Ivip's OITRDs, LISP's PTRs and with APT's and TRRP's similar arrangements, it can provide multihoming, TE and address portability in a scalable fashion, including for all packets sent from hosts in networks without ITRs. So they can, in principle, provide immediate and significant benefits to the end-user networks which adopt the new kind of address space each proposal requires. Doing this without disruption, cost to others, and without host changes anywhere seems pretty "clean" to me compared to trying to convince people to adopt a new system which only provides benefits when they upgrade their hosts, and applications - and then only for communications with other hosts with these upgrades and new apps. (Also, those host-change proposals generally only work on IPv6, so you have to coax everyone over to an Internet where they can't contact all the hosts they can with IPv4.) # Handling path-MTU is a usually problem since the packets in the # core are different than the origin host would recognize. I think it is a solvable problem: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ but those concerns, and the need for protocols, ITR and ETR functions to support this etc. do not exist in Ivip's two "Forwarding" approaches. I think it may be easier to upgrade the DFZ routers with firmware updates, and replace any which can't be upgraded (I would think they are probably all be firmware upgradeable in these respects) than to develop and implement the encapsulation and PMTUD stuff. # Extra bandwidth is consumed by the ITR figuring out whether the ETR # is still available and functioning. This a problem for LISP, APT and TRRP - but not at all for Ivip. The reachability testing system of the end-user network (probably run by some company they hire to do this) does whatever testing the end-user wants, and makes decisions in which ever way they require, without involving ITRs at all. # Border filtering of source addresses becomes problematic. It's a # mess. This is a problem for LISP, APT and TRRP, but not at all for Ivip. Ivip's "forwarding" modes work normally with source address filtering, for instance at the border routers of ISPs, when checking packets arriving from the DFZ. Likewise for Ivip's encapsulation modes, since the outer header source address is that of the sending host. The filtering happens naturally and normally at the ISP border routers - and this is extended to the inner packet by the simple process of the ETRs dropping any packet which has an inner source address which is different from its outer source address. # Deployment may require heavy weight "for the public good" relays in # the non-upgraded part of the Internet to facilitate migration. This is a reference to Ivip's OITRDs (Open ITRs in the DFZ) or LISP's PTRs (Proxy Tunnel Routers). The LISP team seem to have no feasible business plan for this, but there is a good Ivip business plan which doesn't at all rely on charity, someone paying for the benefit of others etc. Business incentives for LISP PTRs and Ivip OITRDs 2008-07-29 http://psg.com/lists/rrg/2008/msg02021.html The OITRDs for any MAB (Mapped Address Block) are paid for by the RUAS (Root Update Authorisation System) organisations which operate each MAB and rent parts of each MAB out to end-user networks to use as micronets. The RUASes pay for the MABs by sampling their traffic patterns and charging their end-user network customers according to which network the traffic is destined to. Ideally, I think, the document you are creating would contain: 1 - Fuller descriptions of the proposals, with the appropriate terminology, ETR, ITR, QSD, PTR, OITRD etc. 2 - Clear labelling of which proposals match which descriptions. 3 - Either a much more fully developed set of critiques, appraisals etc. than you have at present - or none at all. The "Major Criticisms" of Strategy A do not apply to Ivip, yet Ivip is one of the Strategy A proposals. I haven't really followed Strategy B, but I think it involves hosts implementing multihoming, TE and whatever takes the place of address portability. If you are going to include major criticisms, then I think there should be some attempt to mention or link to the concerns about pushing these responsibilities onto hosts. I discussed this in: Fundamental objections to a host-based scalable routing solution http://www.irtf.org/pipermail/rrg/2008-November/000233.html and today in the text I suggest you add to your problem definition: Summary of architectural solution space - problem definition http://www.irtf.org/pipermail/rrg/2008-December/000525.html My view is that any proposal involving such host changes is a non-starter firstly for the fundamental reasons mentioned in the above messages and secondly because there is no way we can convince enough end-user networks to adopt this, since benefits only accrue in proportion to the number of other end-user networks they communicate with who also adopt it. Rewriting apps is just not going to happen on the scale which would make this sort of thing attractive to most end-user networks. This latter argument also applies to any proposal which assumes there will be widespread adoption of IPv6 without the need for IPv4 any time soon. See these messages from Thomas Narten and Keith Moore: http://www.ietf.org/mail-archive/web/ietf/current/msg54376.html http://www.ietf.org/mail-archive/web/ietf/current/msg54392.html http://www.ietf.org/mail-archive/web/ietf/current/msg54409.html I think these Strategy B host upgrade schemes (such as ILNP) are generally only intended for IPv6. What are the proposals covered by Strategy B? Strategy C is "replacing BGP with something different and better". I agree with your "Major Criticisms" that there is no proposal for this which matches the needs of ISPs. Nor is there any proposal which has a chance of being introduced without a complete switch-over to a new system - and there is 0% probability of this becoming feasible in the foreseeable future. Strategy D doesn't address the routing scaling problem as I understand it. FIBs are not the major problem - the RIBs and the overall BGP distributed control plane is the problem, at least when we consider using it for tens or hundreds of millions of prefixes. Strategy E is probably impractical and does not provide the multihoming etc. needed by tens or hundreds of millions of end-user networks. In point 2 of your critique, perhaps you can add, after "users": "to have multihoming, TE and portable address space". Strategy F doesn't solve the problem - but that is what we will do until a lot of people become much more enthusiastic than they currently are about one or more of the proposals! Strategy G doesn't solve the problem either. Regards - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
