[rbridge] Updated charter
erik.nordmark at sun.com (Erik Nordmark) Wed, 02 February 2005 13:16 UTC
From: "erik.nordmark at sun.com"
Date: Wed, 02 Feb 2005 13:16:59 +0000
Subject: [rbridge] Updated charter
In-Reply-To: <200502020150.BBN74825@mira-sjc5-f.cisco.com>
References: <200502020150.BBN74825@mira-sjc5-f.cisco.com>
Message-ID: <420142B7.8090400@sun.com>
X-Date: Wed Feb 2 13:16:59 2005
Michael Smith wrote: >>The solutions that have been discussed will replace the L2 >>headers (at least in some cases, and encapsulate in another >>L2 header in some cases), and not decrement the L3 TTL, which >>is different than a bridge (which doesn't replace the L2 >>header) and a router (which decrements TTL). > > > Some specific examples may help clarify, but the above statement sounds like > the traditional bridge of yore i.e. bridges with ethernet and token ring > interfaces that swap MAC headers to the appropriate canonical format and > encapsulating bridging packets over ATM and Frame Relay using RFC1483 and > RFC1490. I guess there is a difference between the theory of bridges, captured in IEEE standards, and what products actually do. I don't think the IEEE standards talk about what bridges between e.g. Ethernet and Token Ring do, but I recall products doing somethings like handling bit-order issues with the addresses in arp packets, and the need to fragment IP packets due to the different MTUs. Radia's rbridge draft (I think) talks about optimizations for IP where the IP packet would transit a cloud of rbridges unmodified, but where the L2 header might be different on exit than on entry. This isn't a problem for IP, since IP doesn't look at the L2 header, but can't be applied to non-IP (aka unknown to the rbridge) protocols. Erik From erik.nordmark at sun.com Wed Feb 2 16:57:05 2005 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed Feb 2 16:59:05 2005 Subject: [rbridge] Updated charter In-Reply-To: <420024A9.1020308@isi.edu> References: <000901c50896$e2619610$6401a8c0@grayling> <41FFE070.3080405@isi.edu> <420000FB.5030303@sun.com> <42000967.7000700@isi.edu> <420012A1.9070007@sun.com> <420024A9.1020308@isi.edu> Message-ID: <420176E1.2080107@sun.com> Joe Touch wrote: > The basis of the Internet is a single address layer that spans different > link layers. There are numerous problems stemming from the rbridge > basically needing to proxy the semantics of two different L2 systems. The Internet architecture assumes very little about the L2 infrastructure. For instance, it works with L2s that preserve the same L2 header (Ethernet being one example) but also over L2s that only use local identifiers (such as DLCIs in frame relay). I don't see how running IP over a L2 where the L2 headers are different when received than when transmitted will cause problems, as long as the protocols involved in L2 address resolution are handled correctly. So perhaps you can list the numerous problems. > What you're proposing is a router that doesn't decrement the TTL. No. And I think it is in the interest of clarity, especially during these formative times, that we don't reuse old terms for new things. So please call it a hybrid, a rbridge, a frobnits, but not a router or a bridge, since that will confuse things with the routers and bridges that exist today. > That's > not the same as a bridge that uses routing (vs. spanning tree) > internally; the former doesn't include L2 semantics, the latter does. > The latter presumes a single L2 semantics, which is easy to verify. The > former (as you suggest) allows multiple L2s, but does NOT preserve L2 > semantics. What we are talking about is a hybrid, which includes L2 semantics but might not preserve L2 semantics when carrying IP packets. > That means a lot of IP will break where/when the L2s have different > semantics, e.g., NBMA vs. broadcast. We don't have a uniform L2 > emulation protocol on which to base an interoperability layer (the PILC > WG noted some of its expected properties, but didn't spec it out as > such). This work seems like it should avoid L2 translation until that > canonical virtual L2 can be spec'd. I don't think anybody has argued that the protocol will support any L2. What's being suggested is that it support some degree of non-uniformity. And since we are assuming that ARP/ND be used for L2 address resolution there is an unstated assumption that all such L2 support broadcast/multicast. > That the routing inside the rbridge is opaque to things outside the > rbridge. OK, that I understand. I think there is a range of semantics that are possible for the hybrids, and the WG needs to discuss them. At one end we have what you seem to be arguing for, which I'll call strict IEEE 802 bridge equivalence, This means that the cloud of interconnected hybrids behave the same way as an IEEE compliant bridge. I think this means that not only are the L2 headers not modified, but also that the packets are delivered on the ports where an IEEE 802 bridge would deliver them (i.e. all ports for broadcast and multicast). At another end of the scale we have what I'd call "IP works". In this case the cloud of interconnected hybrids collectively exhibit behavior so that IPv*/ARP/ND/DHCP etc work as expected. Note that there are probably interesting points between these scales. One is what existing switch products do for multicast, which is to do IGMP/MLD snooping to limit the spread of multicast. Presumably there are others as well. Erik From erik.nordmark at sun.com Wed Feb 2 16:58:22 2005 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed Feb 2 17:00:44 2005 Subject: [rbridge] Updated charter Message-ID: <4201772E.3080204@sun.com> I generated an update because Margaret asked for one. As part of doing that I've tried to capture something about what has been discussed on the list. Next step is to figure out an agenda for Minneapolis. Erik [Note: name change from IPVLX to TRILL] 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 rbridge 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] Updated charter Erik Nordmark
- [rbridge] Updated charter Pekka Savola
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Erik Nordmark
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Michael Smith
- [rbridge] Updated charter Michael Smith
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Fred L. Templin
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Erik Nordmark
- [rbridge] Updated charter Joe Touch
- [rbridge] updated BOF website Joe Touch
- [rbridge] Updated charter Erik Nordmark
- Re: [rbridge] Updated charter Ralph Droms
- Re: [rbridge] Updated charter Joe Touch
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Eric Gray