Subject: [rbridge] Draft Minneapolis minutes

From: michsmit at cisco.com (Michael Smith (michsmit))
Date: Fri, 8 Apr 2005 11:38:36 -0700

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
>

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri, 08 Apr 2005 14:04:38 -0700

> rbridges happens when learning occurs.  This is independent of topology

Michael,

I don't understand the nature of your comment. The above are notes from 
the presentation about the goals of TRILL. So are you saying that
1. The minutes are incorrect, because that presentation said something 
different?
2. That the goals are unreasonable and a WG should have different goals?
3. That a particular proposed solution for TRILL might not satisfy the 
goals?

Only #1 would be appropriate comments on the minutes, since their 
purpose is to record what was presented/discussed at the meeting.

> discussion was questioning whether the probability can be viewed as

This sure sounds like you are making point #3 above.

   Erik

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri, 08 Apr 2005 14:34:32 -0700

>>rbridges happens when learning occurs.  This is independent of topology
To explain to the technical point you are raising to the llist (because it's
not really a change to the minutes, but is instead a technical point 
that should
be discussed on the list), the strawman draft design does have that 
property, because when endnode A
talks to endnode B, if the RBridges do not yet know where B is, they 
will send it on
a spanning tree, and when they do find out who the egress RBridge is, 
they will send it directly.

A variant that has been discussed is to use the link state information 
to calculate a per-ingress
RBridge spanning tree. Then all the paths will be optimal (except during
topology change). But of course it is more expensive
to calculate all those trees. So it's an engineering tradeoff. MOSPF 
calculated per-source
spanning trees, by the way.

All this stuff is an engineering tradeoff, so we shouldn't necessarily 
assume one thing is
cast in stone if we find out it precludes other good properties. I asked 
what protocols
still depend on in-order delivery, and it didn't seem like a lot of them 
do. And in the
installations with SNA or whatever legacy protocols we're talking about, 
they're not
forced to use RBridges...they could stick with standard bridges.

I'd hope modern protocols are not being designed that would break if 
packets get
reordered.

And if it's OK to sometimes reorder (when topology changes), then I'd 
think it couldn't
be fatal to reorder at other times too.

So, could someone list the protocols that break with reordering, and how 
widely
deployed they are, and whether they need the features of RBridge, or are 
doing just
fine with bridges?

If they are important, AND if they need the features of RBridges rather than
bridges, then RBridges could send unknown destination frames to
a spanning tree rooted at the ingress RBridge, and that would solve the 
problem.

The question again is, are these protocols worth the cost of computing 
all these extra trees?

On the upside if it's considered important enough to do all these trees,
the cost of the extra trees is totally internal to the RBridge (computation,
extra forwarding tables).

And on another upside of the extra trees...for multicast packets for 
high-bandwidth
applications (which will usually be IP multicast applications, so will 
be using IGMP),
having per-ingress RBridge trees, plus pruning based on IGMP snooping, 
will minimize
the number of packet-hops necessary to distribute that data.

Radia