[rbridge] Draft Minneapolis minutes

Erik,
One comment inline. 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark
> Sent: Friday, April 08, 2005 10:23 AM
> To: rbridge at postel.org
> Subject: [rbridge] Draft Minneapolis minutes
> 
> 
> I just realized I need to get these submitted today. So 
> please send in any corrections you have.
> 
>     Erik
> 
> TRILL
> BoF Chair Erik Nordmark <erik.nordmark at 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 optimize 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), 

The text "basically only when topology changes" should be removed.

Rbridging will reorder during a stable topology.  The reordering in
rbridges happens when learning occurs.  This is independent of topology
changes.  

The point argued is that with today's rapid spanning tree there is only
a remote chance of reordering and that is only during a topology change.
Traditional spanning tree has no such reordering whatsoever.  Learning
occurs much more frequently as the L2 tables reach capacity due to churn
of entries.  This would cause rbridges to reorder more frequently as the
L2 tables reach capacity (still a stable network topology).  The
discussion was questioning whether the probability can be viewed as
small.

>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 at 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
> ------------------------------------
> ...
> 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 tunneling... 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.
> 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.
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
> 