On Mon, Nov 24, 2008 at 2:07 AM, Robin Whittle <[EMAIL PROTECTED]> wrote: > http://bill.herrin.us/network/rrgarchitectures.html > > 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.
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? > 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? > 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. > 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. > ETR Address Forwarding (EAF) - for IPv4 > http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw That's a bit broken. You can't discard the fragment offset and MF bit. I'm pretty sure hosts are allowed to pre-fragment the packets and then set the DF bit on each fragment. Hosts routinely fragment UDP and ICMP packets that are too large for the wire, even if they don't set the DF bit. These packets need to successfully cross the core. There's also no point carrying the DF bit if you're not going to carry the fragment offset. By definition those packets are always DF=1. You could rely on the L2 checksum to maintain packet integrity. Many if not most core links are a form of ethernet today anyway, and the rest could theoretically be upgraded. But you're going to need to find some more bits somewhere; 16 isn't enough. I suppose you could steal 4 bits from the header length since there's not a lot of point in passing anything in the core with IP options attached anyway. Just send an "administratively prohibited" message if someone tries to send a packet with options. But that still only buys you 20 bits. ICMP errors are gonna be a bit hairy. Meh. I've included less likely approaches in the document. How about this: 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. > 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. Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
