[rbridge] Choice of routing protocols

[Erik Nordmark]

Below is an excerpt from emails between myself and Bob Hinden that tries
to capture some issues around the choice of routing protocol.
Hopefully this can stimulate further discussion on this topic.

    Erik

-------- Original Message --------
Subject: Re: Late agenda item?:  ipvlx charter
Date: Mon, 31 Jan 2005 10:24:35 -0800
From: Erik Nordmark <erik.nordmark at sun.com>
To: Bob Hinden <bob.hinden at nokia.com>


Bob Hinden wrote:

> I also wonder if we want to consider OSPF for this.  The IETF owns all 
> the IPR and can produce derivative standards, where the situation with 
> ISIS is very different (e.g., OSI owns the basic protocol). It's going 
> to be difficult for an L2 bridge implementor to figure out and 
> understand which collection of IETF and OSI specs to use.  Also, if I 
> remember correctly, ISIS still requires manual configuration of 20 byte 
> OSI NSAP addresses.  This would be a pretty odd thing for a L2 bridge.

AFAIK it is only the 6-byte MAC address that is the 'system ID' in
IS-IS. One would probably need to fill in some dummy value for the AFI
and area, but this can be done without any manual config since each box
is assumed to have a factory assigned unique MAC address.

OSPF is a bit harder in fact, since (even with the IPv6 pieces in
OSPFv3) the OSPF router ID is a 4 byte number, and there isn't any
existing numbering space which could be used to create factory assigned
globally unique 32 bit numbers.

While in principle OSPF is interesting and should be explored, there are
some additional items (in addition to the router ID assignment) which
makes using OSPF harder than IS-IS:
  - the OSPF LSAs are specified to carry fixed length addresses (either
    IPv4 or IPv6), so one would probably need to define a new (set of)
    LSAs for TRILL Not a big deal really, but IS-IS was designed to
    handle variable length NLRI from the start.
  - OSPF is designed to run on top of IP whereas IS-IS runs directly on
    IEEE 802.1. While rbridges (just like bridges) will probably be
    assigned IP addresses for management purposes (SNMP), requiring an IP
    address for the rbridge before it can start OSPF do build the
    topology would be a severe limitation. One would want to allow
    rbridges that don't have IP addresses (e.g. for home), or where the
    IP addresses are assigned after the rbridges have established
    connectivity across the link (assigned using stateless IPv6 or DHCP
    for instance).
    [Bob later told me: A possible choice when using OSPF is to use
    OSPFv3 over IPv6 and IPv6 link-local addresses, since any device with
    an IEEE MAC address can form an IPv6 link-local address.]

So trust me, I did really like to use OSPF here, because of the IS-IS
specification issues but also because there are more open source OSPF
code out there for implementors to reuse.


> While on the general topic, RIPv2 might even be a reasonable choice for 
> routing technology.  It's a lot simpler to implement and would still 
> work a lot better than spanning tree.

TRILL does add one additional constraint on a routing protocol (beyond
carrying MAC addresses around) which is to be able to construct a
spanning tree between the rbridges. The spanning tree is needed for
flooding (ARP, ND, and any other broadcast/multicast). Doing this in a
link state protocol is relatively easy; each router can independently
calculate the spanning tree in a consistent manner. But it is far from
clear whether this can be be done in a distance vector protocol.

Also, part of the goal for TRILL is to be better than the IEEE 802.1D
spanning tree, which has a worst-case convergence time of 45 seconds or
so. It isn't clear that RIP is a good fit for fast convergence.

> My general question is:  Is the decision on the routing technology to be 
> used for this going to be something that the w.g. decides or is it just 
> assumed it is ISIS?  I would favor the former approach, but in either 
> case I think it is important that the charter clarify this.

The TRILL WG would need to make the choice.
If the actual routing protocol work is farmed out to the specific,
long-lived routing protocol WGs, the success would depend on those WGs
having interest in this space.
An option is that the TRILL WG define the
extension to the routing protocols, and just have that reviewed by the
routing protocol WG(s).

    Erik