[rbridge] rbridge-01 comments

[Pekka Savola]

[ re-sending from Sunday -- this probably got stuck in the approval
queue as I wasn't subscribed ]

A couple of high-level comments:

 - is IS-IS trivial enough to implement?  in future, even some stereos or
home equipment might function as rbridges...

 - designated bridge IP protocol support: (this is not just designated
bridges, of course..) -- it seems this approach assumes that all the
rbridges (or at least designated rbridges) support all the IP versions
supported within the site?   Or at least if e.g. v4-only rbridge would be
elected, v6 could fall to the slower path?  What if elsewhere in the site a
v6 rbridge would be elected?

 - it would be very, very desirable (obviously) if there was some trick that
IP MTU could stay at 1500 bytes.  Actually, I guess due to MPLS or
VLANs-in-VLANs lots of Ethernet hardware at least support larger framing --
I just don't know whether that could be leveraged here. (a really
half-baked idea: try to do special marking using VLAN frames -- I just can't
quickly remember how they look like or whether they would be abusable :-)

 - the rbridge design is lucrative especially for smaller campuses
("home networks", which are unmanaged -- if it's managed, it should
have sufficient knowledge to set up routing infrastructure!).  
However, a few things which haven't bene spelled out scare me, as an
operator:

   * larger (campus-wide?) subnets means that spoofing inside a subnet is
also easier, and ingress filtering granularity ("in-prefix spoofing") is
more coarse -- leading to more difficult user tracking.

   * manageability in general is reduced.

   * if you have a single IPv4 pool for campus, or just a couple of them, it
begs the question how you configure the v4 subnet mask, and how you change
it when increasing/decreasing the size?  Maybe trivial with DHCP, but more
challenging than with smaller subnets if you have to use manual
configuration on hosts. (remember that the subnet mask needs to be changed
de-facto immediately everywhere, unless proxy-arp hacks are used, else
in-site communication suffers.)

   * larger subnets do not mean good for firewalling between segments.  Do
you do this at rbridges using MAC's then? :)  I.e., modern enterprises
*have* to include firewalling between different departments, or different
classes of networks.  The rbridge model appears to increase openness (which
is good), but this will likely hamper the effects to keep the users separate
and from harming each other.  (consider e.g., virus/worm propagation inside
a single rbridged subnet.)


Some minor observations:

 - does IS-IS have an "area address" -- wasn't that an OSPF concept?

 - the draft uses quite ipv4-specific terminology in most places (ARP, IGMP)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings