Here is a critique for the RRG Report for Fred Templin's RANGER proposal. Please see these messages for the longer description and discussion.
IRON(RANGER): description and draft critique http://www.ietf.org/mail-archive/web/rrg/current/msg05983.html RW http://www.ietf.org/mail-archive/web/rrg/current/msg05992.html FT http://www.ietf.org/mail-archive/web/rrg/current/msg05996.html RW The first of these links to the reference documents. Below is a longer version of my V2 critique, and a shorter 500 word version for inclusion in the RRG Report. Ideally other people would contribute their own critiques of IRON-RANGER. The shorter version is just the longer one minus paragraphs 3 to 10. The text which follows has been updated based on the above discussions. - Robin Longer Critique V2 ------------------ IRON-RANGER (hereafter "IRON") uses principles from RANGER, VET and SEAL to construct a Core-Edge Separation scalable routing solution. Separate IRON networks would be used for IPv4 and IPv6, but perhaps they could be combined in some way if this was desired. IRON does not have a mapping system such as that of Ivip and the term "mapping system" does not appear in the IDs. However, the IRON architecture does in some ways resemble LISP-ALT, with a flat ALT-structure, with traffic packets being used as map requests and in which the initial traffic packets are delivered to the destination network. Please see (msg05996) for discussion of this. A single global network of IRON routers communicate over tunnels, each using their own BGP instance, to form the IRON BGP control plane. This is unrelated to the DFZ's BGP control plane. IRON routers may be DFZ routers, but here they are assumed not to be. While each IRON router advertises all "edge" prefixes in the routing system of the networks they are based in (of ISPs and large corporations, universities etc.), the current IDs do not call for them to advertise any such prefixes in the DFZ. Therefore, as currently described, IRON could only support packets sent by all hosts if it was adopted by all such networks. However, IRON could easily be adapted to do this by having multiple widely-dispersed IRON routers advertise the complete set of "edge" prefixes in the DFZ. Each IRON router processes packets addressed to "edge" addresses by forwarding them to a particular IRON router which, inside the IRON BGP control plane, advertises a particular Virtual Prefix. There may be one or more of these VP routers for a given prefix, and the number of VP prefixes for the entire "edge" subset of the global unicast address space would be limited, in part, but the ability of the IRON BGP control plane to handle this number of prefixes. IRON routers peer with topologically nearby IRON routers to be their BGP neighbours. When the traffic packet arrives at the VP router, it is forwarded, again via a VET/SEAL tunnel to the IRON router which can deliver the packet to the destination network. The VP router also sends a SEAL redirect message to the first (ITR-like) IRON router and thereafter, that first IRON router tunnels the packets directly to the IRON router which connects to the destination end-user network. The VP router's FIB for has more-specific routes for each end-user network prefix which is covered by this VP. Please see (msg05996) for discussion of how two or more ETR-like IRON routers D and E somehow, continually and securely, register their ability to accept packets for an end-user network prefix, along with their priorities in respect of each other for which should be used if both are reachable - and optionally some instructions for load-sharing between them. The FIB entry for this end-user network prefix in each VP router contains this information. This information is conveyed to an ITR-like IRON router which tunneled the initial packet to the VP router, so that IRON router subsequently tunnels packets to one or both of these ETR-like routers. There is a caching time and an inactivity timer for purging these more-specific routes from the FIB of the ITR-like IRON router. ("ITR" and "ETR" do not appear in IRON - and "ITR-like" means the ITR-like function of an IRON router, since they can also perform ETR-like functions and some of them also perform as VP routers.) There are unresolved design and scaling questions regarding: 1 - The ability of the initial IRON router to handle in its FIB the temporarily installed more-specific routes due to the redirect messages it receives from VP routers. 2 - Likewise, questions of FIB and/or route processor ability to handle the churn in these, since they will typically last for seconds or minutes, before having to be withdrawn and perhaps replaced after a further redirect. 3 - The number of VP routers - more than one would be necessary for robustness. 4 - So far there is no detailed explanation, for IPv4 or IPv6, of how the ETR-like functions of IRON routers continually and securely register each end-user network prefix they handle - together with priority and load sharing information - with one or more VP routers which could be located anywhere in the world. Only once a detailed description is available could the scalability, robustness, responsiveness and security of this process be estimated. IRON is not yet described in sufficient detail for these questions to be answered. Mobility support is apparently limited to mobile IPv6 networks with prefixes up to /56 in length, with mobility of devices to be handled by conventional MIPv6 processes. There is no current description of the business relationships between the various users and operators of routers - so it is difficult to envisage business arrangements in which costs are generally borne by those who benefit, without unfair burdens being placed on any participants. Nor is there a description of how IRON could be introduced so as to provide portability, multihoming etc. for all packets received by an adopting network, before all networks have their own IRON routers. IRON is a novel CES architecture in an early stage of its design process. It can be decentralised in every respect, and uses data-driven "redirect" messages as a form of mapping distribution. However, it is not yet clear how the VP routers learn the mapping for the end-user prefixes in their VP. If this can be done in a secure, fast and scalable fashion - then IRON may be worth considering as a scalable routing system, at least for providing portability and multihoming to non-mobile end-user networks. 468 word critique V2 -------------------- IRON-RANGER (hereafter "IRON") uses principles from RANGER, VET and SEAL to construct a Core-Edge Separation scalable routing solution. Separate IRON networks would be used for IPv4 and IPv6, but perhaps they could be combined in some way if this was desired. IRON does not have a mapping system such as that of Ivip and the term "mapping system" does not appear in the IDs. However, the IRON architecture does in some ways resemble LISP-ALT, with a flat ALT-structure, with traffic packets being used as map requests and in which the initial traffic packets are delivered to the destination network. There are unresolved design and scaling questions regarding: 1 - The ability of the initial IRON router to handle in its FIB the temporarily installed more-specific routes due to the redirect messages it receives from VP routers. 2 - Likewise, questions of FIB and/or route processor ability to handle the churn in these, since they will typically last for seconds or minutes, before having to be withdrawn and perhaps replaced after a further redirect. 3 - The number of VP routers - more than one would be necessary for robustness. 4 - So far there is no detailed explanation, for IPv4 or IPv6, of how the ETR-like functions of IRON routers continually and securely register each end-user network prefix they handle - together with priority and load sharing information - with one or more VP routers which could be located anywhere in the world. Only once a detailed description is available could the scalability, robustness, responsiveness and security of this process be estimated. IRON is not yet described in sufficient detail for these questions to be answered. Mobility support is apparently limited to mobile IPv6 networks with prefixes up to /56 in length, with mobility of devices to be handled by conventional MIPv6 processes. There is no current description of the business relationships between the various users and operators of routers - so it is difficult to envisage business arrangements in which costs are generally borne by those who benefit, without unfair burdens being placed on any participants. Nor is there a description of how IRON could be introduced so as to provide portability, multihoming etc. for all packets received by an adopting network, before all networks have their own IRON routers. IRON is a novel CES architecture in an early stage of its design process. It can be decentralised in every respect, and uses data-driven "redirect" messages as a form of mapping distribution. However, it is not yet clear how the VP routers learn the mapping for the end-user prefixes in their VP. If this can be done in a secure, fast and scalable fashion - then IRON may be worth considering as a scalable routing system, at least for providing portability and multihoming to non-mobile end-user networks. _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
