|
IPVLX
Agenda ====== - problem statement (nordmark) - exploring 3 possible approaches * automatic prefix assignment (orman) * L2 bridges (perlman) * rbridges (perlman) - How do the 3 approaches match the problem statement (nordmark) - Discussion Problem statement ================= Intro - L2 advantages/disadvantages - IP router advantages/disadvantages - combine the best of both worlds Constraints - Host and router behavior remain unchanged - Inter-operate with existing bridges Desirable properties - various.. Savola: security, across a large campus. Filtering is often done on subnet boundaries or using address ranges, but there won't be this network structure in a large amorphous network. Manageability using address structure will be harder. Nordmark: large bridged network and large routed network have different starting points for security. Narten: all nodes on this network are in the "same security zone" which might limit applicability. Nordmark: can build logical equivalent of vlans on top.. gagliano: provisioning for big networks needs to be considered. Particularly port-based. summerfeld: look at it as: replace large unmanageable bridged network with better L2 network rather than deleting functionality found in IP routers today. touch: look at it as: augmentation of existing L2 functionality hinden: I'm interested in having a /64 device (cell phone) which renders "routing" service to devices behind it, but I don't want to configure it as a router. Does this help? nordmark: not necessarily, this is not going after that, this focuses on a different problem, although some solutions might help your case as well. Automatic Prefix Assignment (Orman) =================================== Layer addressing characteristics L2 - unrelated to topology L3 - addressing related to topology Routers and subnets start without IP addresses. IP addresses: fixed-prefix|subnet-numbers|host-number * subnet numbers might have further structure Requirements - join, leave partition, rejoin and have subnets still work - .. Approaches: - central authority allocates subnet addresses * issue: deal with reliability - distributed agreement protocol * issue: slow startup * issue: partitions/re-join may require renumbering * issue: node mobility may require renumbering, without mobileip or something similar * issue: address utilization not great narten: prefix assignments is not required by the problem statement (e.g. could flat route host-routes instead) unknown: spanning tree has a size limit of 7 hops and there are scaling issues in time taken to discover loops daley: spanning tree only gives us distance to the root bridge orman: routing protocols can scale.. montenegro: wireless isn't mentioned, mesh networking? Rbridges Transparent Routing ============================ Goals - glue links together, still one IP subnet - zero configuration - compatible with: existing bridges, existing IP nodes What's wrong with bridges? - non-optimal routes - temporary loops are a disaster - choice of meltdowns or conservative failover Basic idea of a transparent bridge.. Spanning tree is loop free, but temporary loops do occur. SP gets rid of them by being very conservative in turning on connectivity, but folks turn down the delay which causes meltdowns (Boston hospital). SP - learn location based on source address, then forward based on station learning. loops are a disaster: no hop count!!! and exponential proliferation Diagram of inefficient forwarding paths in a spanning tree Mythology: 7 hop limit is not a magic number Bridges are slow to start forwarding - because of timer (30 secs) which waits a while to learn of topology changes before turning on forwarding - congestion can get the bridge protocol pkts to be lost, which enables more links for forwarding, which compounds the problem Routers also have temp loops but there is a ttl and no multiplication of numbers of packets Desirables Rbridges - like routers, terminate the spanning tree - like bridges, transparent - encapsulate packets between rbridges - learn location of IP and mac address - link state algorithm between rbridges (ospf, is-is) Encapsulation header - outer L2 header must not confuse L2 bridges - distinguish originating from transit traffic (to no learn from transit traffic) - specify next recipient (to not multiply # pkts) - hop count Need spanning tree for flooding - of broadcasts (e.g. ARPs) Learning - can be done by listening to ARPs, data traffic Optimization for IP - a designated router can ping hosts Daley: ARP/ND etc can be used rather than ping. Daley: are you interested in the optimality of the STP, for example rbridges could become the root bridge Dave Plunkett: uses 802.1w RSTP, still run into trouble. Is there an stepwise approach? Start with L2 spanning tree + link-state? Leave out the L3 optimizations til later? perlman: IEEE not doing link-state, works fine for pure L2 Gagliano: has not MPLS solved these problems? l2vpn? Perlman: we want to work with existing switches austein: smarter bridges, no protection for broadcast storms perlman: yes, but routers do that fine today ssm-guy: why is this an IETF thing? IP encapsulation instead? touch: requires IP paths touch: l2vpns model an enclave of networks as some other network. This models a network as a device, a bridge orman: is there a problem with the MTU when you encapsulate perlman: yes, but may not be an issue orman: how big will these things get? perlman: same scale as today, possibly bigger, single-ospf or single-isis domain orman: larger it gets, the more security will be an issue unknown: overlap with l2vpns. Did not see coverage of multicast. perlman: can optimize multicast, yet to be worked out huitema: security.. l2 routing protocol takes in unauthenticated host/address mapping and propagates this around perlman: doing no harm... summerfeld: improvement, if it is used at the same scale as bridging is today Preserve the existing ARP duplicate response detection behavior. Would like same L3 address, multiple L2 connections daley: interesting assumptions being made: keep the existing L2 domains and therefore 1500 byte MTUs table size in switches in the core touch: the table size is only the size of the number of rbridges on the edges montenegro: Even if you assume rbridges only learn via SeND, there is an attack whereby remote hosts on the internet can ping random nodes within the prefix (which could be the size of Sydney) just to create the distributed ARP storms that rbridges run amongst each other. nordmark: scalability is naturally limited because this is a simple broadcast domain. templin: MTU issue.. link-adaptation, ICMP messages, .. narten: wired/wireless -- two links with same subnet prefix gagliano: security: routing protocols can be secured, and that is a plus. What routing protocol and what changes? unknown: suggested reference: "turn prevention" INFOCOMM 2001 touch: different from replacing STP with link-state because the encapsulation makes the whole thing look like a single bridge unknown: mac-in-mac encapsulation -- backbone bridges samita: how to handle mobile hosts? perlman: there's no "hello" message from end nodes, so that is not reliable. Local rbridges can poll end-nodes fairly frequently nordmark: can watch traffic too unknown: costs of running routing protocols in bridges..concern about packet re-ordering perlman: take care with path-splitting. thaler: ping/polling. pinging a device that wants to go to sleep may cause it to wake it up. passive is better. montenegro: Seems to me like wireless will happen with this as well, so what is the relationship with .11s (meshes) and/or BSS/ESS via IAPP? Donald Eastlake: I'm the chair of .11s and am here talking to these folks. unknown: 802.11s is working on almost exactly the same thing 802.11s is currently evaluating approaches narten: how much larger does this need to scale? huitema: IP-only is not a good thing Would like to see this in the IEEE nordmark: no competition with IEEE nordmark: who is interested in working on this? only 3-4 people not interested hinden/nordmark: should this be done in the IETF or IEEE 802 roughly 2:1 IETF:IEEE why are you interested: daley: scalability of bridged networks segmenting STP domains helps transparent and passive is critical for mobile devices MLD/IGMP could be used to poll for devices tim shepherd: very interesting, not sure it is a good idea do routing, security issues need to be addressed orman: scalability and easy operational requirement -- don't need to configure. charter needs to spell out L2/L3 optimizations clearly. ???: "surgical approach" -- do something stepwise. L3 awareness could be considered divisive as MPLS is divisive x?X: samsung/home networking. plug and play. non-compatible link-layers. touch: don't necessarily need to look at L3 at all in order to do something sensible. IETF understands routing. and the core of this is routing. This is corresponding to l2vpn. 123: another l2vpn. Maybe this should be merged into the l2vpn group. ???: would prefer not to have this merged into l2vpn is interested in this if this will make bridged networks more efficient than what we have today. Scaling larger is not a big deal. This is not a l2vpn. narten: l2vpn is extending l2-over-wan |