[rbridge] Conflicts to avoid for BoF/WG?
Radia Perlman
Radia.Perlman at Sun.COM
Fri Feb 4 13:03:09 PST 2005
Is it possible to request that this not be Friday? A lot of people make
plane reservations
early assuming that they don't want to stay on Friday.
As for the agenda...looks great. I'm happy to lead any of the
discussions below
if you don't have other volunteers. Though for the one you have me down
for (mixing
L2 link types) I can talk about some ways of doing it, but I'm still not
really clear
on why people want this, and what types of links they'd like to mix. Is
there
someone who would like to talk about the problem statement?
Radia
Erik Nordmark wrote:
>
> 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 at sun.com>
>
> Mailing list: rbridge at 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 mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
More information about the rbridge
mailing list