- 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)
- L2 advantages/disadvantages
- IP router advantages/disadvantages
- combine the best of both worlds
- Host and router behavior remain unchanged
- Inter-operate with existing bridges
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
- join, leave partition, rejoin and have subnets still work
- 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
- 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
- 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
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