Subject: [rbridge] Draft BoF minutes

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Mon Sep 13 06:22:35 2004

Sorry for the delay.
Here are the draft minutes composed based on notes by Aidan Williams and 
Gabriel Montenegro.

Please send me any comments today as I need to submit this for the 
proceedings tomorrow.

    Erik

-------------- next part --------------

Agenda
======
  - problem statement			(nordmark)
  - exploring 3 possible approaches
    * automatic prefix assignment	(orman)
    * L2 bridges			(perlman)
    * rbridges				(perlman)
  - How do the 3 approaches match the problem statement (nordmark)
  - Discussion

Problem statement
=================
  Intro
  - L2 advantages/disadvantages
  - IP router advantages/disadvantages
  - combine the best of both worlds
  Constraints
  - Host and router behavior remain unchanged
  - Inter-operate with existing bridges
  Desirable properties
  - various..

  Savola: security, across a large campus.  Filtering is often done on
  subnet boundaries or using address ranges, but there won't be this
  network structure in a large amorphous network.  Manageability using
  address structure will be harder.

  Nordmark: large bridged network and large routed network have
  different starting points for security.

  Narten: all nodes on this network are in the "same security zone"
  which might limit applicability.

  Nordmark: can build logical equivalent of vlans on top..

  gagliano: provisioning for big networks needs to be considered.
  Particularly port-based.

  summerfeld: look at it as: replace large unmanageable bridged
  network with better L2 network rather than deleting functionality
  found in IP routers today.

  touch: look at it as: augmentation of existing L2 functionality

  hinden: I'm interested in having a /64 device (cell phone) which renders 
  "routing" service to devices behind it, but I don't want to configure it as 
  a router. Does this help?

  nordmark: not necessarily, this is not going after that, this focuses on 
  a different problem, although some solutions might help your case as well.

Automatic Prefix Assignment (Orman)
===================================
  Layer addressing characteristics
  L2 - unrelated to topology
  L3 - addressing related to topology

  Routers and subnets start without IP addresses.
  IP addresses:  fixed-prefix|subnet-numbers|host-number
    * subnet numbers might have further structure
  Requirements
  - join, leave partition, rejoin and have subnets still work
  - ..
  Approaches:
  - central authority allocates subnet addresses
    * issue: deal with reliability
  - distributed agreement protocol
    * issue: slow startup
    * issue: partitions/re-join may require renumbering
    * issue: node mobility may require renumbering, without mobileip
      or something similar
    * issue: address utilization not great

  narten: prefix assignments is not required by the problem statement
  	  (e.g. could flat route host-routes instead)

  unknown: spanning tree has a size limit of 7 hops and there are
  	   scaling issues in time taken to discover loops

  daley: spanning tree only gives us distance to the root bridge

  orman: routing protocols can scale..

  montenegro: wireless isn't mentioned, mesh networking?

Rbridges Transparent Routing
============================
  Goals
  - glue links together, still one IP subnet
  - zero configuration
  - compatible with: existing bridges, existing IP nodes
  What's wrong with bridges?
  - non-optimal routes
  - temporary loops are a disaster
  - choice of meltdowns or conservative failover
  Basic idea of a transparent bridge..

  Spanning tree is loop free, but temporary loops do occur. SP gets rid of them
  by being very conservative in turning on connectivity, but folks turn down 
  the delay which causes meltdowns (Boston hospital).

  SP - learn location based on source address, then forward based on station 
  learning.
  loops are a disaster: no hop count!!! and exponential proliferation

  Diagram of inefficient forwarding paths in a spanning tree
  Mythology: 7 hop limit is not a magic number

  Bridges are slow to start forwarding
  - because of timer (30 secs) which waits a while to learn of
    topology changes before turning on forwarding
  - congestion can get the bridge protocol pkts to be lost,
    which enables more links for forwarding, which compounds the problem

  Routers also have temp loops but there is a ttl and no multiplication of 
  numbers of packets

  Desirables
  Rbridges
  - like routers, terminate the spanning tree
  - like bridges, transparent
  - encapsulate packets between rbridges
  - learn location of IP and mac address
  - link state algorithm between rbridges (ospf, is-is)
  Encapsulation header
  - outer L2 header must not confuse L2 bridges
  - distinguish originating from transit traffic (to no learn from
    transit traffic)
  - specify next recipient (to not multiply # pkts)
  - hop count

  Need spanning tree for flooding
  - of broadcasts (e.g. ARPs)
  Learning
  - can be done by listening to ARPs, data traffic
  Optimization for IP
  - a designated router can ping hosts

  Daley: ARP/ND etc can be used rather than ping.
  Daley: are you interested in the optimality of the STP, for example
  	 rbridges could become the root bridge

  Dave Plunkett: uses 802.1w RSTP, still run into trouble.
       		 Is there an stepwise approach?
		 Start with L2 spanning tree + link-state?
		 Leave out the L3 optimizations til later?

  perlman: IEEE not doing link-state, works fine for pure L2

  Gagliano: has not MPLS solved these problems?  l2vpn?
  Perlman: we want to work with existing switches

  austein: smarter bridges, no protection for broadcast storms
  perlman: yes, but routers do that fine today

  ssm-guy: why is this an IETF thing?
  	   IP encapsulation instead?
  touch: requires IP paths

  touch: l2vpns model an enclave of networks as some other network.
  	 This models a network as a device, a bridge

  orman: is there a problem with the MTU when you encapsulate
  perlman: yes, but may not be an issue

  orman: how big will these things get?
  perlman: same scale as today, possibly bigger, single-ospf or
  	   single-isis domain
  orman: larger it gets, the more security will be an issue

  unknown: overlap with l2vpns.  Did not see coverage of multicast.
  perlman: can optimize multicast, yet to be worked out

  huitema: security..  l2 routing protocol takes in unauthenticated
  	   host/address mapping and propagates this around
  perlman: doing no harm...
  summerfeld: improvement, if it is used at the same scale as bridging
  	      is today
  	      Preserve the existing ARP duplicate response detection
  	      behavior.
	      Would like same L3 address, multiple L2 connections

  daley: interesting assumptions being made: keep the existing L2
  	 domains and therefore 1500 byte MTUs
	 table size in switches in the core
  touch: the table size is only the size of the number of rbridges on
  	 the edges

  montenegro: Even if you assume rbridges only learn via SeND, there is an 
              attack whereby remote hosts on the internet can ping random 
              nodes within the prefix (which could be the size of Sydney) just
              to create the distributed ARP storms that rbridges
              run amongst each other.

  nordmark: scalability is naturally limited because this is a simple
  	    broadcast domain.

  templin: MTU issue.. link-adaptation, ICMP messages, ..

  narten: wired/wireless -- two links with same subnet prefix

  gagliano: security: routing protocols can be secured, and that is a
  	    plus.  What routing protocol and what changes?

  unknown: suggested reference: "turn prevention" INFOCOMM 2001
  touch: different from replacing STP with link-state because the
  	 encapsulation makes the whole thing look like a single bridge
  unknown: mac-in-mac encapsulation -- backbone bridges

  samita: how to handle mobile hosts?
  perlman: there's no "hello" message from end nodes, so that is not reliable.
           Local rbridges can poll end-nodes fairly frequently
  nordmark: can watch traffic too

  unknown: costs of running routing protocols in bridges..
  	   concern about packet re-ordering
  perlman: take care with path-splitting.

  thaler: ping/polling.  pinging a device that wants to go to sleep
  	  may cause it to wake it up.  passive is better.

  montenegro: Seems to me like wireless will happen with this as well, 
  so what is the relationship with .11s (meshes) and/or BSS/ESS via IAPP?

  Donald Eastman: I'm the chair of .11s and am here talking to
  these folks.

  unknown: 802.11s is working on almost exactly the same thing
  	   802.11s is currently evaluating approaches

  narten: how much larger does this need to scale?

  huitema: IP-only is not a good thing
  	   Would like to see this in the IEEE

  nordmark: no competition with IEEE

  nordmark: who is interested in working on this?
  	    only 3-4 people not interested

  hinden/nordmark: should this be done in the IETF or IEEE 802
    roughly 2:1 IETF:IEEE

  why are you interested:
  daley: scalability of bridged networks
  	 segmenting STP domains helps
	 transparent and passive is critical for mobile devices
	 MLD/IGMP could be used to poll for devices

  tim shepherd: very interesting, not sure it is a good idea
      do routing, security issues need to be addressed

  orman: scalability and easy operational requirement -- don't need
  	 to configure.  charter needs to spell out L2/L3
  	 optimizations clearly.

  ???: "surgical approach" -- do something stepwise.  L3 awareness
       could be considered divisive as MPLS is divisive

  x?X: samsung/home networking.  plug and play.  non-compatible
       link-layers. 

  touch: don't necessarily need to look at L3 at all in order to do
  	 something sensible.  IETF understands routing. and the core
  	 of this is routing.  This is corresponding to l2vpn.

  123: another l2vpn.  Maybe this should be merged into the l2vpn group.
  ???: would prefer not to have this merged into l2vpn
  	   is interested in this if this will make bridged networks
	   more efficient than what we have today.
	   Scaling larger is not a big deal.
	   This is not a l2vpn.
  narten: l2vpn is extending l2-over-wan

---

From: Cheng-Yin.Lee at alcatel.com (Cheng-Yin Lee)
Date: Mon Sep 13 07:23:38 2004

Erik,
What is the conclusion of the BoF?
WIll there be a WG?

Thanks!
Cheng-Yin

Erik Nordmark wrote:

>   ------------------------------------------------------------------------
>
> Agenda
> ======
>   ------------------------------------------------------------------------
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Mon Sep 13 08:13:36 2004

> What is the conclusion of the BoF?

Not yet clear AFAIK.

    Erik