[rbridge] Choice of routing protocols
erik.nordmark at sun.com (Erik Nordmark) Fri, 04 February 2005 11:58 UTC
From: "erik.nordmark at sun.com"
Date: Fri, 04 Feb 2005 11:58:55 +0000
Subject: [rbridge] Choice of routing protocols
Message-ID: <4203D3BA.2050306@sun.com>
X-Date: Fri Feb 4 11:58:55 2005
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@sun.com> To: Bob Hinden <bob.hinden@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 From erik.nordmark at sun.com Fri Feb 4 12:03:30 2005 From: erik.nordmark at sun.com (Erik Nordmark) Date: Fri Feb 4 12:04:52 2005 Subject: [rbridge] Conflicts to avoid for BoF/WG? Message-ID: <4203D512.505@sun.com> Are there other conflicts which we must avoid? Erik This might be approved as a WG before the meeting, but we will schedule it as a BoF for the time being. a. Working Group or BOF full name with acronym in brackets: TRansparent Interconnection of Lots of Links (TRILL) b. AREA under which Working Group or BOF appears: INT c. CONFLICTS you wish to avoid, please be as specific as possible: multi6, shim6, ipv6, v6ops, is-is, ospf d. Expected Attendance (figures from the previous IETF are sent when WG/BOF scheduling opens) 100 (based on IPVLX BoF) e. Special requests (i.e. multicast): f. Number of slots: 1 g. Length of slot: 2 1/2 hours Bof Description: See proposed charter below. This is a follow-on to the IPVLX BoF in Aug 2004 Bof Chair: Erik Nordmark <erik.nordmark@sun.com> Mailing list: rbridge@postel.org Subscribe: http://www.postel.org/mailman/listinfo/rbridge Web page: http://www.postel.org/rbridge/ With additional information as well as mailing list archives Agenda: ------- - Welcome and Administrivia 5 minutes Chair - Charter review 10 minutes Chair - Problem statement discussion 30 minutes 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? - Threats and security considerations 10 minutes ??? What should the goal be? What can we do better? - Requirements on routing protocols 20 minutes ??? For zero configuration Carrying MAC addresses Broadcast IS-IS vs. OSPF vs. something else - Connecting different L2 types 30 minutes Radia Perlman? - Choices for ARP/ND 10 minutes ??? Constraints from security discussion (intentionally duplicate L2 addresses), mobility, SeND support, etc. - Choices for broadcast/multicast 10 minutes ??? Worth doing any optimizations? Spanning tree between rbridges? Proposed charter: ----------------- TRansparent Interconnection of Lots of Links (TRILL) While IEEE 802 bridges are attractive due to not needing explicit configuration and allowing hosts to move within the bridged topology, they are more limited than IP routers since bridges only support IEEE 802 technologies, and the most common layer 2 interconnection method (dynamically created spanning tree formation using bridges) is not as flexible and robust as layer 3 routing. The WG will design a hybrid solution that combines the simplicity of configuration while taking full advantage of complex topologies. The design should have the following properties: - zero configuration of the hybrid devices - ability for hosts to move without changing their IP address - it should be possible to forward packets using pair-wise shortest paths, and exploit the redundant paths through the network for increased aggregate bandwidth - possible optimizations for ARP and Neighbor Discovery packets (potentially avoid flooding all the time) - support Secure Neighbor Discovery - the packet header should have a hop count for robustness in the presence of temporary routing loops - nodes should be able to have multiple attachments to the network - no delay when a new node is attached to the network - multicast should work (and after a re-charter it might make sense to look at optimizations for IP multicast) - be no less secure than existing bridges (and explore whether the protocol can make "L2 address theft" harder or easier to detect) A required piece of the solution is an IP routing protocol which is extended to carry L2 address reachability, handle broadcast, and is friendly to zero-configuration. Likely candidate are the link-state routing protocols since they can easily be extended to provide for broadcast, which is believed to be difficult for distance vector protocols. This working group will define the requirements on such routing protocol(s), and select the routing protocol(s) to be used. The intent is that the actual extensions to the routing protocol(s) be performed in the WGs with expertise in the routing protocol(s). The working group will look into solutions that can interconnect different layer 2 technologies, and also look at providing support for non-IP protocols, even though one can not combine those two features together; the interconnection of different layer 2 technologies (with different layer 2 address formats) will most likely only work for the IP family of protocols. Whether the same or different address formats are used, there might be a need to handle different MTUs. The WG will design a protocol that combines the benefits of bridges and routers in a way that will co-exist with existing hosts, IP routers and bridges. The design must support both IPv4 and IPv6 The working group will not work any layer 3 aspects except to provide - Possible optimizations for ARP and ND packets (not always flooded everywhere) - Being able to carry IP broadcast and multicast packets (which might just fall out from supporting L2 multicast) - Defining the L3 operations needed to interconnect different L2 technologies The work consists of several, separable pieces: - Defining the requirement on the routing protocol(s), and select one or more routing protocols. The detailed specification of the extensions to a particular routing protocol will be left as an action item for the specific routing protocol WG. - Defining what information must be carried in an encapsulation header for data packets, and how to map that information to various link types (e.g., IEEE LAN, Fibrechannel, MPLS) - Defining how address resolution (ARP and Neighbor Discovery) is performed, taking into account the desire to be compatible with Secure Neighbor Discovery. - Defining how the solution extends to the case when multiple layer 2 technologies, that have different address format/length, are interconnected. Deliverables - A short draft on the problem statement and goals - A document defining what information needs to be carried in routing protocols to support the trill concept, and other requirements on the routing protocols. - Encapsulation draft specifying what needs to be carried in general and the specific format to use on IEEE LANs - ARP and ND draft - Draft on interconnecting different types of layer 2 technologies - Threat analysis document Goals and Milestones Jun 05 Problem statement and Goals submitted to IESG for Informational Sep 05 Routing protocol support requirements to IESG for Informational Dec 05 Encapsulation document to IESG for Proposed Standard Sep 05 ARP & ND to IESG for Proposed Standard Mar 06 Interconnecting Layer 2 Technologies document to IESG for Proposed Standard Dec 05 Threat analysis to IESG for Informational ---
- [rbridge] Choice of routing protocols Erik Nordmark
- [rbridge] Choice of routing protocols Fred L. Templin
- [rbridge] Choice of routing protocols Fred L. Templin
- [rbridge] Choice of routing protocols Hilarie Orman
- [rbridge] Choice of routing protocols Fred L. Templin
- [rbridge] Choice of routing protocols Pekka Savola
- [rbridge] Choice of routing protocols Erik Nordmark