Notes taken at IETF 55 ====================== Bill Woodcock (Packet Clearing House) interested * Idea: use routing registry to announce atoms at. * Vulnerability: the specific transition mechanism we are proposing, that of using Class E space, or some similar constrained and easily-identifiable block, and breaking it into /32s to represent the atoms, is elegant but creates a very particular and obvious target. Someone could disrupt _everyone_ in the transition by announcing bogus host routes. (What if someone didn't like atoms idea.) Might put testers off? [ Patrick: in addition entities (atoms rather than prefixes), it becomes easer to create bogus routes, and Internet is easier to attack. In particular, if we installed atom-based routers at sites, those sites would be vulnerable to such attack. However, BGP security might be more manageable with fewer entities (unclear). ] * Can help out. Has exchanges in other countries. No yelling customers. Research interests. Need to think of a way to introduce without damage to testers. Could inject routes our (atom ids). Might be able to place box there (edge router)? * Somewhat related: the idea of clustering routers in one location in an AS, which multihop BGP with clusters in other ASes (one such cluster per AS). Outside the clusters, what are currently routers can be replaced by simple switches, which download computations from the cluster. This should reduce convergence problems. This idea has been floating around for a long time but has never been written down. Advantage to atoms: easier to migrate to atoms (since fewer routers to transition) Suggests: would be good if Andre did analysus (e.g. at Agilent) to study this idea. Nevil Brownlee: * If atoms are fairly stable, misrouting might not be too serious, if we can forward on to correct destination from the wrong destination. Ronald van der Pol: * What is never accounted for in the project proposal is that ISPs use IGP to route/forward across their networks. The model suggested in the proposal only contains BGP routers, and ignores protocol others than BGP. In any case this may have consequences for the part of the proposal that talks about having an island of *only* atomised routers. Vixie (very brief): * Effect we are dealing with is too small. It is outstripped by routing table growth. * If ISPs are provisioned for atoms, an event where deaggrageation takes place will cause overloading of ISPs since multihomed customers have diversity in their secondary links. [ Patrick: I think he means that if some ISP becomes unreachable to its customers, those customers will switch to their secondary links, and since the customers have very different secondary links the original atom (corresponding to the ISP) is replaced by a large number of alternative atoms (as many as there are different secondary links among the customers). I think he's making an important point which applies to computed crown atoms: the secondary links may not be visible in the atom's system of AS paths, since crown atoms are computed only considering the parts of AS paths that are within the scope. (Am I making sense?) Under declared atoms though (or computed atoms that do not have a limited scope), his argument should not apply, since in that case the secondary links are visible from the beginning and are part of the original atom. ] Andrew Partan: Main points: * What does it buy you? * If atoms are defined administratively, then it might buy you something. Otherwise not (reachability, flapping). * What if a prefix shows up in multiple atoms? [ Andre: In the future, we might perhaps allow atoms to share prefixes, even aggregate atoms into super-atoms. ] * Multihomed ASes that don't do BGP. Increasing number of companies want multiple presences but not an AS: o An AS number costs money. o You don't necessarily want to run BGP. For example: web servers. We should talk to web hosting folks. (It is unclear how much this occurs.) [ Andre: Perhaps we should have 'atom aggregators' between customers and the backbone. * Mistakes by humans. * Analogy with 8+8. In 8+8 an IPv6 address consists of two components: the internet locator, which is used for routing, and the internet identifier, which identifies a single host independent of its location in the network. The atom ID / prefix distinction is (or can be) somewhat similar to an internet locators and internet identifiers, respectively. The atom ID is used to route to destinations, allowing prefixes to be used as location-independent identifiers. Aside: this is a monopoly power issue. Separating the locator from end system ID creates more independence from providers. [ Patrick: Differences between 8+8 and atomised routing: o An 8+8 internet identifier identifies a single host; a prefix identifies a network. o In 8+8 the internet locator and internet id are embedded in the IPv6 address. In atomised routing, the atom ID is attached to a packet, not by the sending host but by a router, and removed from the packet before it reaches the destination. As a consequence, the prefix *is* used for routing (1) before the packet is tagged, (2) after the packet is untagged. o Several 8+8 internet locators can be associated with an internet identifier (leading to several 8+8 addresses with the same internet identifier but with different locators). In atomised routing, there is only one atom ID per prefix. See multihoming below. o Multihoming. In 8+8 a sending host is responsible for finding alternative paths to a multihomed destination. DNS is used by sending hosts to obtain alternative 8+8 addresses for the same multihomed destination, each containing a different locator part (corresponding to different providers of the destination), but the same identifier part. The input to the mapping is an internet identifier, e.g. obtained from an 8+8 address already known by the sending host. Multiple paths to a multihomed destination are available through these different addresses. In atomised routing, as in traditional BGP routing, multihoming is handled by routers. There is only one atom ID for a destination. An atom ID identifies a system of AS paths, and any multihoming is captured by that system of AS paths. ] Other comments. [ Patrick: Many of these apply only under the assumption that we use computed atoms, rather than declared atoms ] : * How do you define the region? * Offline computation takes too long, dynamic updates are at a finer granularity. * What if a prefix disconnects? You need to update the atom definitions. Who does that? * What if one prefix is flapping? [ Comment by Andre: same as with aggregation, It should be buffered (assuming declared atoms) ] * What about route reflectors and confederations? [ Patrick: Andrew was reasoning that clients of a RR have more information under atom-based routing than before ABR: they now have access to the system of AS paths of an atom. But that isn't the case: during routing (when making routing decisions), atoms are represented by an atom ID, not by their system of AS paths. The only time that the system of AS paths might be propagated is during atom computation (before routing). ] [ Andre: There should be no difference there with prefix-based routing. We might be able to recast an AS confederation as an atom. ] * What about decisions that are made locally and are not visible in the AS paths, e.g. local pref? How does that affect atom computation? [ Andre/Patrick: it doesn't. Local decision can equally well be applied to atoms in precisely the same way as prefixes. ] Geoff Huston/Frank Kastenholz o Observation: if everyone were single homed, there would never be a need to withdraw a prefix when it becomes unreachable. Traffic will simply be carried towards the prefix to the point where a link is down (the link that causes the prefix to be unreachable). The only reason the prefix might be withdrawn is to avoid carrying such traffic. In particular the ISP that 'contains' the prefix might object to carrying such traffic. o Renumbering is hard. Atomising is easy: it does not affect hosts or the packets that they send. o The mapping of atom<->prefixes is fairly stable. o We should measure stability. o Forwarding table size is not a problem. o Two reasons for routing updates: (1) a link goes down (2) administrative o If one prefix gets dampened how do you not dampen the whole atom? o They object to encapsulation. It is too hard/expensive. Cengiz (Packet Design): o On using routing registries (see Bill Woodcock). Is pro-routing registry, but has come to realise that they don't work in practice. For example, UUnet does not register. Any implementation based on a routing registry would have to make use of *partial* info. This might work: simply require that if someone wants to use atoms, then they must register. o On how to allow take into account policy that is not defined by the origin AS: * A customer might pay its providers not to differentiate between prefixes in an atom declared by the customer (could be part of the service offered by the provider to its customer). * Peering relationships are a problem, since that is not a customer/ provider relationship. We might need to 'redeclare' atoms at that point. * The top tiers don't have a lot of policy. It may therefore be feasible to (a) have customers declare atoms based on their policy (b) have providers (up to a certain level) modify (e.g. split) those atoms, giving the final definition of atoms. * Suspects that declaration of atoms at origin AS is a good idea. o Thoughts relating to Andrew Partan's comments: * Cannot think of a reason why a route reflector or AS confederations would be problematic. * Multihomed ASes that do not speak BGP can be a problem. Believes that these cases are rare, or at least not growing fast. See http://www.packetdesign.com/docs/cengiz.pdf, slide 12, the blue line (multihomed w/ multiple origins). Andrew Partan is skeptical about that since it is very hard to observe these cases [Patrick: does skitter data provide a better view?] * [Patrick: I can't make sense of this point anymore ] As to 'Decisions not apparent to AS path changes (e.g. local pref) ', can think of a problem: e.g. between two ASes A and B there are two points where they connect, and local pref is being in B done to forward some prefixes to one connection, other half to other conection. This is not visible in AS paths externally. If one link fails there will be a short time when routing changes. ??? Andrew Partan/Frank Kastenholz * Anything out of the ordinary during forwarding (tagging a packet whether by encapsulation or something else) is expensive: routers are not optimised to do it. It becomes less expensive as tagging gets done nearer to the source of a packet, since there the routers are smaller anyway. * We don't know how performance gets hurt most, whether it's the number of prefixes, the amount of communication, the dynamics. We should simulate to find out. * Frank recommends a clear architecture in which atom computation/ declaration, distribution of atom<->prefix mapping, and packet forwarding are clearly separated, allowing for alternatives to implement each of these three components. Dave Meyer o Our forwarding scheme is very much like tunneling and it would be helpful to present it as such. o Initially, our forwarding scheme may look very expensive: modifying an IP packet in whatever way is an expensive operation. However, tagging a packet during forwarding is not a fundamentally different operation than MPLS labeling. Therefore, it may be that the cost will be acceptable. Note that MPLS relabels at every hop in the LSP, whereas we tag only once. See Andrew Partan comments for costs that we incur that MPLS does not. o Feels that a lot of detail is missing in the proposal about forwarding, routing, distribution of atoms<->prefixes mapping. o Reservation of an IP address range for atom IDs may be hard to get, since atoms IDs are not global entities. [ Patrick: I don't think that is true. They are global entities. What are the criteria for obtaining such an allocation?] o Important aspect of atoms is information hiding/reduction. o On table size vs dynamics of routing vs protocol bandwidth. * Any IPv4-based forwarding table size can be accommodated by buying more hardware. (There are only so many IPv4 addresses.) Dave * Routing table dynamics are important. * Protocol bandwidth is an important issue too. (Refers to Cengiz' talk on peering losses at iptomaine http://www.packetdesign.com/docs/ptomaine.pdf.) Dave suggests it would be a good idea to see if atoms can cut down on communication costs. [Patrick: Further comments, from before I explained verbally, Some of these may not be relevant anymore after explaining. I should check with him. The ones that I do think are still relevant I have marked with ### ] o Red flags: 1. LSR 2. Name space issues / overhead, e.g. atom<->prefix mapping/discovery (configuration). ### 3. How do you build the "AIB" (FIB), and use it to do things like load balancing, uRPF, "per-atom" accounting. 4. Can I do dynamic classification of prefixes<=>atoms, and/or dynamic atom "names" 5. What is the effect of another level of indirection on OPS. E.g., I have prefix / AS, now prefix/ atom-1/.../atom-i/.../atom-n (in the nested case). ### 6. If the internal routers don't know the prefixes, can I traceroute? I guess this one works, because the IGP knows the next hops. 7. Source routing. ### o Since atoms hide information, have you analysed the corresponding reduction in CPU load (due to the aggregation)? o Can a router "deaggregate" or "proxy aggregate" atoms? o Confirms remark in project proposal that IPv6 routing architecture will be fundamentally similar to the IPv4 architecture.