[rbridge] Draft Minneapolis minutes

[erik.nordmark at sun.com (Erik Nordmark)]

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),
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.