[rbridge] Choice of routing protocols

[Pekka Savola]

On Fri, 4 Feb 2005, Erik Nordmark wrote:
> 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.

I'd also like to consider using OSPF as a basis for the simple reason 
that it has been widely implemented by the same vendors we'd like to 
ship Rbridges.  Those low-end router manufacturers don't implement 
IS-IS, so this would incur a steeper curve for implementation.

However, as for IPv6 one would have to use OSPFv3 as a basis (and then 
one could use draft-ietf-ospf-af-alt-01.txt), not OSPFv2, this does 
not seem to be all that relevant consideration anymore because those 
low-end vendors don't implement OSPFv3 in any case.

That said, the arguments below seem to indicate that using OSPF has 
some serious issues (mainly relating to IP address assignment) and 
IS-IS may be a better fit, with an automated NSAP address 
"generation".

To avoid rehashing this discussion over and over again, these 
considerations should be nailed down in the charter or an 
internet-draft.

> -------- 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
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
>

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