Last Modified: 2005-02-07
|
TRILL BoF Chair Erik Nordmark <erik.nordmark@sun.com> 1. Welcome and Administrivia, Erik Nordmark ------------------------------------------- Scribe: Donald Eastlake, ... 2. Problem statement discussion, Erik Nordmark ---------------------------------------------- Including the "service" that a cloud of hybrid devices will provide, whether it is equivalent to IEEE 802.1D devices, or handles IP packets differently. When is it ok to reorder packets? MTU considerations? L2 solutions have many benefits. Will use IEEE 802 networks as an example but can apply to Fibrechannel, MPLS, etc. We also have L3 technology which may provide benefits in terms of robustness, etc. There is a desire to combine the above to create best of both worlds for a LAN (where a LAN is approximately a broadcast domain). Motivations: better robustness, better aggregate bandwidth than L2 bridges, better latency, user of shortest path, ability to interconnect different L2 types?, bigger LANs? TRILL Model Goals: zero configuration, hosts can move without changing IP address, use best pair-wise paths and be able to load split, maybe optimise ARP / ND (don't always flood), secure ND, hop count to reduce damage from loops, multiple external attachment point support, no delay for new host attachment, support for multicast, to be no less secure than existing bridges, no changes to hosts, routers, or L2 bridges, support non-IP protocols, handle IPv4&6, maybe interconnect different L2 technologies. There are lots of questions about mobility, which goals are high level, etc. LAN Service is: broadcast domain, small probability of reordering and duplication (basically only when topology changes), MTU (most LANs have uniform MTUs). Question of fitting L2 info into current size caches... Q: What about wireless? Nordmark: TRILL is independent of whether links are wireless. Which LAN service does IP need? Some special cases for IPv4/IPv6 ARP may improve service but perhaps it is better if ARP doesn't need special treatment. 3. Threats and security considerations, Marcelo Bagnulo. -------------------------------------------------------- Security goals: minimum is same as current bridges. New features may enable usage beyond the capabilities of classic bridges. ... Examples of attacks presented for bridges and Rbridges. Q: Does this security analysis take into account all of the ongoing and proposed security and QoS work in IEEE 802.1? Nordmark: No. Q: Why are we considering these details presuming a solution? Nordmark: It is good to start considering security from the beginning. Mark Townsley: This is a little deep for this stage although some good things came out of it. Let's move on. 4. ARP/ND and Broadcast/Multicast Issues ---------------------------------------- Joe Touch and Yu-Shun Wang (presented by Yu-Shun Wang as Joe Touch had a conflict) Various questions of exact size of network, what a campus means, what a bridge is, what the goals are, ... DAD ... DNA ... Real networks all have VLANs. Q: How can you detect a device if it's moving and not connected and someone takes its MAC address? Wang: Not worried about MAC addresses, I was talking about IPv4/6 addresses. Q: Are you trying to solve duplicate MAC address problem? Wang: No. 5. Requirements on routing protocols, Alex Zinin, zinin@psg.com --------------------------------------------------------------- Alex presented considerable material on scalability functions for different types of overhead. Paul Congdon: Do you consider dynamic VLAN formation in the core? Zinin: No, only static VLAN in my analysis so far. ... Margaret Wasserman: Do you have a comparison with RSTP? Zinin: Not in this presentation. ... Reachability is less volatile than activity. ... Advantages of reachability. "CNLS(?)" announces all hosts and works. The built in protocol limits on update rates are not enough to assure stability. Recommend using a single routing instance over all VLANs but restricted flooding of information only to nodes that need that information. Q: Are you assuming station number scales with VLANs? A: No, but there are typically more stations in systems with many VLANs. 6. TRILL issue: VLANs, Radia Perlman ------------------------------------ Presented a modified design, where the "egress RBridge" is included in the header (between the outer header, which bridges would see, and the inner frame which is exactly as transmitted by the endnode). Forwarding is to the egress RBridge. This enables the core to forward solely based on egress RBridge, and not need to have endnode addresses in forwarding tables. It also means that only RBridges attached to a particular VLAN need to know about the endnodes in that VLAN. Margaret Wasserman: Would Rbridge flooding zones be IP subnets? Radia Perlman: No. [Later Radia posted an email saying that different Rbridge VLANs would be separate IP subnets.] Wasserman: What would happen with mobility? Perlman: You can keep same IP if you move. Comment: All this should be compared with what's in 802.1, 802.1ah, MAC in MAC encapsulation, etc. Q: GVRPN MAC tunnelling... Is there parallel work in L2VPN? Daly: Reminds me of similar aspects of RFC 2357(?) Like MPLS. Q: What is the scope? Looks like BGPv3, ..., in same enterprise. Nordmark: This is not being proposed for the Internet backbone. Q: Is there a conflict with L2VPN? Both seem to be used for aggregation. 7. Connecting different L2 types, Radia Perlman ----------------------------------------------- Forwarding between different link types works for IP but probably too hard in general for incompatible link types. This presentation of mine is to try to convince people NOT to include Rbridging different types of links in the scope of the proposed WG. Comments: All comments made opposed doing this between different types of links. 8. Discussion ------------- Nordmark: The intended network scope where this would be applied is not "provider" but "local". Comment: "Provider" is not the same as "wide area". Comment: We should figure out what has been done elsewhere. Nordmark: I've been looking for that. No one else is doing shortest path. Comment: Big overlap with L2VPN. VPLS area in L2VPN. Shortest path for unicast. GMPLS. Issues with packet re-ordering and MAC address. The alternative of encapsulating in IP header means you can then just use IP on intermediate nodes so only edge devices need to learn MAC addresses. Nordmark: But IP does not autoconfigure. Paul Congdon: There seems to be more awareness of what 802.1 is doing. Original list of goals included shortest path. That is not addressed by IEEE 802.1 but I think the other goals are addressed by 802.1. Nordmark: Link state with limited flooding would solve scalability. That technique might also fit into L2VPN. Bob Hinden: Haven't heard clear case as to why this is better than alternatives. Nordmark: shortest path, nothing else provides it. Hinden: You can do a lot of things with routers, can you do something better with them? Nordmark: We've tried that with the ZROUTER BoF. I was there. But you still have to change address when you move. Hinden to Radia: Why didn't you invent this when you invented STP (the spanning tree protocol)? Radia Perlman: I wasn't provided with the whole problem, just told to develop a spanning protocol. At that point in time they would never have considered adding an encapsulation header. It would have made the devices too complex, and there were hard limits on frame sizes. Zinin: Big difference between this and L2VPN is that L2VPN uses IP while this defines forwarding and routing in L2. X does solve the problem with state in core devices but that's not the problem. Critical problem is edge bridge problem. Would rather try to solve problem with IP. Nordmark: We tried that and gave up. Margaret Wasserman: How many in the room are on the rbridge mailing list and read it? (Many hand go up.) Wasserman: How many have support from their management to work on this? Quite a few indicate they do.) Wasserman: Three choice poll: (1) ready to work on this, (2) interesting think but we need to look further, (3) no work should be done on this in the IETF. (1) ~10. (2) Many (3) ~12. Wasserman: The rough consensus is to look into this further. |