Hi Bill, Regarding your 3rd draft:
http://bill.herrin.us/network/rrgarchitectures.html and my comments: http://www.irtf.org/pipermail/rrg/2008-November/000172.html http://www.irtf.org/pipermail/rrg/2008-November/000216.html I accept that you don't want to go into the differences between encapsulation and forwarding - however, it does affect some other things, such as PMTUD and source address filtering. You wrote in: http://www.irtf.org/pipermail/rrg/2008-November/000212.html My inclination is that if it's a full push to any of the map servers then its a full push system. ... I'm open to arguments why that viewpoint is wrong. and I replied (msg 216) that I think this description and its A2b description doesn't adequately describe Ivip or APT. I don't see any change in any of the A2 options. I think APT and Ivip need a separate description. I describe them as "hybrid push-pull" systems. If you leave your page as it is, perhaps you could add a footnote pointing to this message in the archives saying that I think some further descriptions are needed to cover Ivip, at least: 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. Likewise, I see no change in the A3 section. To encompass Ivip, I think something like this needs to be added: 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. I understand you don't consider OITRDs and PTRs as part of the architecture, but I think they are an essential element of Ivip and LISP which is not covered in your page at present. I don't see any changes in the A4 descriptions. I wrote that A4d is a good description of Ivip's approach to PMTUD problems: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ On second thoughts, A4d is not a good description at all. Here is an attempt at describing Ivip's "IPTM: ITR Probes Tunnel MTU" approach. 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. That is about as good a description as I can think of without making it a lot longer. It is a complex thing to do, but I think it will work. Your description doesn't cover Ivip's two forwarding modes: ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ Here is an attempt to do so: A4g For IPv4, all DFZ and some internal routers are upgraded so that an alternative format of IPv4 header can be used. The "Evil bit" is set to 1 and 30 bits of the RLOC address is encoded into the header, with routers forwarding the packet according to that address, rather than the destination address. The ETR restores the header and forwards the packet to the end-user network. This involves no encapsulation overhead or PMTUD problems, but fragmentable packets longer than a certain length are dropped by the encoder. BTW, I think dropping overly long fragmentable packets is just fine - applications have had more than a decade to get over burdening the network with fragmenting their too long packets. 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. Here are some comments on your summary of the major criticisms of the various approaches to Strategy A: * There don't appear to be any genuinely clean ways of implementing * strategy A. Handling path-MTU is a problem since the packets in * the core are different than the origin host would recognize. This doesn't apply to the two forwarding approaches. I know it is radical to suggest altering DFZ routers, but maybe it is not so hard to do. The IPv4 approach only concerns the FIB, and the IPv6 approach also involves the RIB to a certain extent. AFAIK, these could be done with firmware upgrades. There is no change at all to the BGP implementation. Maybe this would be easier than trying to develop and deploy the more complex ITRs required to handle the PMTUD problems. * Extra bandwidth is consumed by the ITR figuring out whether the * ETR is still available and functioning. This doesn't apply to Ivip, since the ITRs don't do any reachability testing. The end-user network typically would hire a specialised company to continually probe reachability of its network via all the ETRs, and to update the mapping accordingly, but that is an entirely user-selectable burden of probing, and it does not affect ITRs. * Border filtering of source addresses becomes problematic. It's a * mess. I think this is a fair description of LISP, APT and TRRP. This is not so with Ivip's forwarding approaches - the filtering happens normally and naturally with those. Nor is it a problem with Ivip's encapsulation approach of using the sending host's address as the source address of the encapsulation header (LISP, APT and I guess TRRP use the ITR's address as the outer source address). Ivip's approach of: 1 - Outer source address = sending host's address. 2 - ETRs drop any packet where the inner source address does not match the outer source address. solves the problem neatly. The ISP's border routers carry on as usual, rejecting packets with a source address matching a list of internal addresses. There's nothing more to do. When, as with LISP, APT and TRRP, the outer source address is that of the ITR, then the only way of implementing this source address filtering is to implement it at every ETR. This would be extremely expensive and unwieldy, since there might be a large number of ETRs this list has to be sent to - and because the only fast way to do the filtering is with hardware (TCAM?), or a rather large lookup table in RAM. * Deployment may require heavy weight "for the public good" relays * in the non-upgraded part of the Internet to facilitate migration. This doesn't match Ivip's OITRD business model at all. They would be paid for by the organisation who has the MAB (Mapped Address Block) which they split up into smaller spaces and rent to end-user networks. Business incentives for LISP PTRs and Ivip OITRDs http://psg.com/lists/rrg/2008/msg02021.html 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 haven't yet read the Strategies B to F. - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
